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Introduction 


This book discusses the subject of lava tubes on Earth, the Moon 
and Mars, and their potential applications for habitats and 
planetary settlements. To implement this, we need robotic 
explorers that can scout the lava tubes. This book will discuss an 
approach for that, using Cube-Xs, which are standardized 
architectures, based on the Cubesat model. Lava tubes are primary 
caves, not formed from the erosion of softer rock. We will discuss 
autonomous exploration of the Lava tubes by multiple units, acting 
together as a team. We will also mention the transportation of the 
units to the site of interest. Lava tubes may be entered from the 
top, through their “skylight”, by winching down. If a tunnel 
opening is found, they can enter in that manner as well. 


We will also discuss how swarms of co-operating autonomous 
Cube-Xs would be a better approach than a single larger model. 


There is strength in numbers, and economy in standardization. This 
section will discuss the employment of swarms of Cube-x units in 
exploring lavatubes. The Cubesat architecture will be used in all 
aspects of the mission. There will be Cubesat-based rovers for the 
exploration, a cubesat-based lander which will deploy the 
explorers, and possibly an orbiting communication relay. The 
modular design of the Cubes-X units will allow sharing of 
common elements across diverse vehicles. 


Even as I type, a 6-wheeled exploration robot from NASA Ames 
has been deployed in Valentine Cave in the Lava Beds National 
Monument in Northern California. The Project is called Braille, 
Biologic and Resource Analog Investigations in Low Light 
Environments. The robot is named CaveR. You can't get anywhere 
without good acronyms. The robot resembles the Opportunity 
Mars rover. It is primarily searching for subterranean microbes, 
and the interaction between underground geology and biology. 
They are, essentially, looking for microbes that survive by eating 


rocks. 


Dedication 


This book is dedicated to Nicholas Sullivan, who introduced me to 
Speleology in high school, and dragged me through numerous 
dirty, smelly, wet caves. He was friends with my father, and a 
level-walker on the C&O Canal. He explored caves on every 
continent, and discovered new cave fauna, and donated it to the 
Smithsonian. He is also responsible for me meeting my future 
wife, in Dead Horse Cave. 


Author 


The author received a Bachelors degree in Electrical Engineering 
from Carnegie-Mellon University, and Masters Degrees in Physics 
and Computer Science from the Johns Hopkins University. 


He was glued to the black & white TV for the launch of the 
Vanguard, the U. S.'s first satellite, through the Apollo missions. 


He began his career in Aerospace with Fairchild Industries on the 
ATS-6 (Applications Technology Satellite-6), program, a 
communication satellite that developed much of the technology for 
the TDRSS (Tracking and Data Relay Satellite System). At 
Fairchild, Mr. Stakem made the amazing discovery that computers 
were put onboard the spacecraft. He quickly made himself the 
expert on their support. He followed the ATS-6 Program through 
its operation phase, and worked on other projects at NASA’s 
Goddard Space Flight Center including the Hubble Space 
Telescope, the International Ultraviolet Explorer (IUE), the Solar 
Maximum Mission (SMM), some of the Landsat missions, and 
others. He was posted to NASA’s Jet Propulsion Laboratory for the 
MARS-Jupiter-Saturn (MJS-77), which later became the Voyager 
mission. It is still operating and returning data from outside the 
solar system at this writing. He worked on a Marshall Space Flight 
Center Lunar Lava Tube Project in 1988. 


Mr. Stakem was affiliated with the Whiting School of Engineering 
of the Johns Hopkins University. He received NASA's Space 
Shuttle Program Managers commendation award, as well as two 
NASA Group Achievement awards, the NASA Apollo-Soyuz Test 
Program Award, and a Certificate of Appreciation, NASA Earth 
Science Technology Office. Mr. Stakem has completed over 42 
NASA Certification Courses in various areas. 


He participated in two summer sessions of NASA/Goddard Space 
Flight Center's Engineering Bootcamp, bring together student 
teams from the Western hemisphere to design, implement, and 
deploy Grover, the Greenland Rover. Grover hosted an ice- 
penetrating radar to map the depth of the ice sheet. 


He also was responsible for 2 summer sessions of a Cubesat 
Project at Capital Technology University, involving teams from the 
Brazilian Scientific Mobility Program. During these sessions, the 
students pushed the edge of the technology for Cubesat and Cube- 
Xs. This resulted in multiple technical papers and presentations. 


Terrestrial Lava tubes 


Any planet or satellite that has volcanism is a good candidate for 
lava tubes. We can visit and explore them on Earth, and do the 
same, at least on the Moon and Mars. They have, as we shall see, 
great potential as habitats. 


Lava tubes drain molten lava from a volcano, then harden when the 
flow of hot lava ceases. They are really a type of cave. The ceiling 
forms first, as the molten lava flows on the ground. The crusting 
over of the lava as it cools forms the tube. Another mechanism is 
referred to as Pahoehoe flow. This is where a surface flow can 
congeal into tubes as well. 


Lava is a low-viscosity fluid, depending on temperature. They 
have been observed as nearly 50 feet wide, and can be found down 
to 50 feet from the surface. One developed from the Mauna Loa 
flow in 1859 extends 50 kilometers under the sea. Interestingly, the 


largest known lava tubes are on Venus. 


A main lava tube can have secondary tubes as well. Theyc an have 
stalactites, sometimes called lavacicles. Stalagmites may also grow 
up from the floor. Lava tubes and caves have their own 
microclimate. 


A lava fan can form at the end of a tube emerging from the ground. 


A skylight, section where the tube has partially collapsed, leaving a 
circular opening, can be spotted by orbital imaging. This 
phenomena has been observed on the Moon. 


From available observational data, Lunar and Martian lava tubes 
are bigger than those on Earth, perhaps hundreds of meters wide, 
and tens of kilometers long, The roof thickness is estimated to be 
meters. 


Initially, it will be NASA and other country's Space agency's 
interest in locating, exploring, and exploiting lava tubes. The 
private sector will not be far behind. 


Lava tubes can possibly be sealed and pressurized to provide living 
and work spaces that would not require a bulky pressure suit, and 
would be inherently radiation shielded. 


Mars' and the Moon's environments are very different. The moon 
has essentially no atmosphere, and is dusty. Mars has sandstorms. 
Mars is more likely to have subsurface water. Neither has much of 
a magnetic field to deflect energetic particles. Both could be used 
as underground habitats for crewed bases. 


Lunar Lava Tubes 


On the Moon, lava tubes may form some 500 meters in diameter, 
before they collapse due to gravity. The LRO spacecraft has 
spotted more than 200 skylights. The Indian and Japanese imaging 
missions have also spotted lunar lava tubes. LRO started with a 
resolution of half-a-meter resolution, but this have approved to a 
quarter of a meter since the orbit has been decaying, putting the 


saellite closer to the lunar surface. 


NASA's Lunar Reconnaissance Orbiter was launched in 2009, and 
is in a polar mapping orbit. It has allowed NASA to assemble a 3- 
D map of the Moon's surface with more than 98% coverage, and 
100 meter resolution. It is a project of the Goddard Space Flight 
Center. 


It has been joined by the Indian Chandrayaan-1 orbiter/mapper. It 
has also discovered lava tube locations on the lunar surface. One is 
near the equator, and is some 2 kilometers in length, 360 meters 
wide. 


In 2011, NASA's Grail mission conducted lunar gravitation field 
mapping. There were two spacecraft. The distance between the 
spacecrafts was carefully calculated, so the lunar gravity field 
could be mapped in great detail. This showed some anomaly's, 
which could be sub-surface voids. On the Moon, due to reduced 
gravity, the angle of repose of the regolith is greater, so slopes are 
steeper. 


On the surface, a Ground Penetrating Radar unit would be most 
helpful in locating the lave tubes and caves. The could be carried 
by an agile ground robot, with some climbing ability. The Chinese 
rover Yutu used a GPR unit on the lunar surface in 2013, but had 
some problems, and was unable to move after the second lunar 
night. It did, however, find some 9 distinct lunar rock layers. The 
GPR unit could also determine the ceiling thickness. The skylight 
feature has been noted in several areas of the moon. The Cube-X 
would provide a good platform for a LIDAR scanner, which could 
produce a 3D model of the cave as the rover goes along. 


H. G. Wells mentioned, in his science fiction novel First Men in 
the Moon, large underground tubes and spaces used by the Selenes 
for housing and manufacturing. 


Martian Lava Tubes & Caves 


Numerous lava tubes occur on Mount Olympus. Partially collapsed 


tubes have been imaged as lines of pit craters, with large lava fans 
at the end. The Caves of Mars Project was accomplished by 
NASA's Institute for Advanced Concepts in early 2000. 


NASA scientists studying pictures from the Odyssey spacecraft in 
Mars orbit spotted what might be seven caves on the flanks of the 
Arsia Mons volcano. The pit entrances measure from 100 to 252 
meters wide and are thought to be at least 73 to 96 meters deep. 
Odyssey also discovered sub-surface water ice near the equator. 


Both ESA and NASA have an interest in the detection, 
characterization, and mapping of lunar and Martian Caves 


Cubesats 


In this section, we will introduce Cubesats, and suggest a group of 
Cubesats is a better platform for exploration that one or two large 
spacecraft. In particular, exploration of lava tubes as potential 
shelters and habitats lends itself well to groups of smaller 
explorers. 


A Cubesat is a small, affordable satellite that can be developed and 
launched by college, high schools, and even individuals. The 
specifications were developed by Academia in 1999. The basic 
structure is a 10 centimeter cube, (volume of 1 liter) weighing less 
than 1.33 kilograms. This allows multiples of these standardized 
packages to be launched as secondary payloads on other missions. 
A Cubesat dispenser has been developed, the Poly-PicoSat Orbital 
Deployer, P-POD, that holds multiple Cubesats and dispenses them 
on orbit. They can also be launched from the Space Station, via a 
custom airlock. ESA, the United States, and Russia provide launch 
services. The Cubesat origin lies with Prof. Twiggs of Stanford 
University and was proposed as a vehicle to support hands-on 
university-level space education and opportunities for low-cost 
space access. This was at a presentation at the University Space 
Systems Symposium in Hawaii in November of 1999. 


Build costs can be lower than $10,000, with launch costs ranging 
around $100,000, a most cost-effective price for achieving orbit. 
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The low orbits of the Cubesats insure eventual reentry into the 
atmosphere, so they do not contribute to the orbital debris problem. 


Central to the Cubesat concept is the standardization of the 
interface between the launch vehicle and the spacecraft, which 
allows developers to pool together for launch and so reduce costs 
and increase opportunities. As a university-led initiative, Cubesat 
developers have advocated many cost-saving mechanisms, namely: 


e A reduction in project management and quality assurance 
roles . 


e Use of student labor with expert oversight to design, build 
and test key subsystems. 


e Reliance on non-space-rated Commercial-Off-The-Shelf 
(COTS) components . 


¢ Limited or no built-in redundancy (often compensated for 
by the parallel development of Cubesats) . 


e Access to launch opportunities through standardized launch 
interfaces. 


e Use of amateur communication frequency bands and 
support from amateur ground stations. 


e Simplicity in design, architecture and objective . 


Multiple flashcubes can be carried as secondary payloads on 
military and commercial flights, Cubesats, as small, inexpensive 
units have a higher mission risk tolerance. 


Since the initial proposal of the concept, further efforts have been 
made to define internal and external interfaces made by various 
developers of Cubesat subsystems, products, and services that have 
defined the Cubesat standard as it is today. A core strength of the 
Cubesat is its recognition of the need for flexibility in the 
definition of standards, and since conception the standard has 
evolved to ensure that these design rules are as open as possible. 
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The most significant of these further advances in definition have 
been for the deployer systems, in order to meet launch 
requirements, and the modularization of the internal electronics. 


A simple Cubesat flight controller can be developed from a 
standard embedded computing platform such as the Arduino or 
Raspberry Pi. The lack of radiation hardness can be balanced by 
the short on-orbit lifetime. The main drivers for a Cubesat flight 
computer are small size, small power consumption, wide 
functionality, and flexibility. In addition, a wide temperature range 
is desirable. The architecture should support a real time operating 
system, but, in the simplest case, a simple loop program with 
interrupt support can work. 


Another important and related aspect in the design approach is that 
of modularity in a complete and integrated Cubesat life cycle, 
effectively representing a modular system of systems. The 
accelerated life cycle demonstrated consistently by small satellites, 
and harnessed by many Cubesat developers, can be further 
enhanced by the application of modularity to the complete life 
cycle. 


The Cubesat Design Specification 


The Cubesat Design Specification, developed by California 
Polytechnic State University, defines the physical and interface 
specifications for Cubesats, and gives testing requirements for 
vibration, thermal-vacuum tests, and shock, as well as safety. Since 
a Cubesat flys with other Cubesats in a deployment device, and 
with a primary payload, safety is a concern. Cubesats are expected 
to have an on-orbit lifetime of less than 30 years. 


Here is a synopsis of CubeSat requirements: These requirements 
were designed for Cubesat missions to Earth orbit, sharing a 
launch vehicle. They might be modified for Cubesat dedicated 
missions to the lunar or Martian surface. 
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Each satellite may not exceed 1 kg of mass. That restriction can be 
relaxed if they are not operating as a satellite. 


The Cubesat Specification suggests the use of Aluminum 7075 or 
6061-T6 for the main structure. If other materials are used, the 
thermal expansion coefficient must be similar to that of Aluminum 
7075-T3. 


Power 


CubeSats with rechargeable batteries must have the capability to 
receive a transmitter shutdown command, compliant, with FCC 
regulations. 


There are emerging standards for larger Cubesats, such as 6U (12 
kg, 12 x 24 x 36 cm), 12U (24 kg, 23 x 24 x 36 cm) and 27U (54 
kg, 34 x 35 x 36 cm). These allow the canister to constrain Cubesat 
deployables such as antennae and solar array. In the original 
Cubesat specification, this task had to be handled by the Cubesat 
itself. Even as they get bigger, the standard architecture and 
modularity of the Cubesat remains a game-changing advantage. 
There are other requirements that apply if we are using a Cubesat 
as a Satellite. 


Cube-X 


Cube-X is a concept derived from Cubesats. A Cube-X can be as 
simple as a Cubesat sitting on a mobility platform. “Cubesat” is 
taken here as a general concept for the electronics of a mobile 
sensor platform. “-X” here stands for explorer. Cubesats are a class 
of smallsats, usually headed for orbit. We can use the modular 
approach and economy of scale that Cubesats provide, to apply 
them to other domains. On Earth, they can be used as explorers on 
land, under the ground, on water, as submersibles, and in the air. 
The mobility platform changes, the concept and electronics stays 
the same. I evolved the phrase, Earth Rovers, to cover these and 


12 


larger units. I realized these units were simply satellites at a much 
lower orbit. Then, it begins to make sense. 


Radiation Environment and Effects 


The Radiation environment on the surface of both the Moon and 
Mars is harsh. It needs to be addressed, even if the robot explorer 
is to spend most of its time underground. The moon has essentially 
no atmosphere, and is constantly bombarded by the solar wind. 
Mars has a slight atmosphere, and can see very high winds. 


The moon has essentially no magnetic field, so no van Allen Belts 
to capture and deflect charged particles. Mars doesn't have a 
magnetic field per se, but the solar wind interacts with the 
atmosphere to form a magnetosphere. Even so, the effects of the 
solar wind are seen on the surface of Mars 


There are two radiation problem areas: cumulative dose, and single 
event. Operating above the Van Allen belts of particles trapped in 
Earth’s magnetic flux lines, spacecraft are exposed to the full fury 
of the Universe. Earth’s magnetic poles do not align with the 
rotational poles, so the Van Allen belts dip to around 200 
kilometers in the South Atlantic, leaving a region called the South 
Atlantic Anomaly. The magnetic field lines are good at deflecting 
charged particles, but mostly useless against electromagnetic 
radiation and uncharged particles such as neutrons. 


The Moon, Earth, and Mars are constantly immersed in the solar 
wind, a flow of hot plasma emitted by the Sun in all directions, a 
result of the two-million-degree heat of the Sun's outermost layer, 
the Corona. The solar wind usually reaches Earth with a velocity 
around 400 km/s, with a density around 5 ions/cm’. During 
magnetic storms on the Sun, flows can be several times faster, and 
stronger. The Sun has an eleven year cycle of maxima. A solar flare 
is a large explosion in the Sun's atmosphere that can release as 
much as 6 x 10” joules of energy in one event, equal to about one 
sixth of the Sun’s total energy output every second. Solar flares are 
frequently coincident with sun spots. Solar flares, being releases of 
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large amounts of energy, can trigger Coronal Mass Ejections, and 
accelerate lighter particles like protons to near the speed of light. 


The Solar wind is made up of particles, electrons up to 10 Million 
electron volts (MeV), and protons up to 100 Mev — all ionizing 
doses. One charged particle can knock thousands of secondary 
electrons loose from the semiconductor lattice, causing noise, 
spikes, and current surges. Since memory elements are capacitors, 
they can be damaged or discharged, essentially changing state. 


Galactic Cosmic rays are actually heavy ions, not originating in 
our solar system. The actual origin is unknown. They carry 
massive amounts of energy, up into the billions (10°) of electron 
volts. These make it to the lunar and Martian surface as well. 


Radiation Hardness Issues for Lunar and Martian 
Spacecraft 


The tolerance of semiconductor devices to radiation must be 
examined in the light of their damage susceptibility. The problems 
fall into two broad categories, those caused by cumulative dose, 
and those transient events caused by asynchronous very energetic 
particles, such as those experienced during a period of intense solar 
flare activity. The unit of absorbed dose of radiation is the rad, 
representing the absorption of 100 ergs of energy per gram of 
material. A kilo-rad is one thousand rads. At 10k rad, death in 
humans is almost instantaneous. 


Absorbed radiation can cause temporary or permanent changes in 
the semiconductor material. Usually neutrons, being uncharged, do 
minimal damage, but energetic protons and electrons cause lattice 
or ionization damage in the material, and resultant parametric 
changes. For example, the leakage current can increase, or bit 
states can change. Certain technologies and manufacturing 
processes are known to produce devices that are less susceptible to 
damage than others. More expensive substrate materials such as 
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diamond or sapphire help to make the device more tolerant of 
radiation, but much more expensive. 


Cumulative radiation dose causes a charge trapping in the oxide 
layers, which manifests as a parametric change in the devices. 
Total dose effects may be a function of the dose rate, and annealing 
of the device may occur, especially at elevated temperatures. 
Annealing refers to the self-healing of radiation induced defects. 
This can take minutes to months, and is not applicable for lattice 
damage. The internal memory or registers of the cpu are the most 
susceptible area of the chip, and are usually deactivated for 
operations in a radiation environment. The gross indication of 
radiation damage is the increased power consumption of the 
device, and one researcher reported a doubling of the power 
consumption at failure. In addition, failed devices would operate at 
a lower clock rate, leading to speculation that a key timing 
parameter was being effected in this case. 


Single event upsets (seu's) are the response of the device to direct 
high energy isotropic flux, such as cosmic rays, or the secondary 
effects of high energy particles colliding with other matter (such as 
shielding). Large transient currents may result, causing changes in 
logic state (bit flips), unforeseen operation, device latch-up, or 
burnout. The transient currents can be monitored as an indicator of 
the onset of SEU problems. After SEU, the results on the operation 
of the processor are unpredictable. Mitigation of problems caused 
by SEU's involves self-test, memory scrubbing, and forced resets. 


The LET (linear energy transfer) is a measure of the incoming 
particles' delivery of ionizing energy to the device. Latch-up refers 
to the inadvertent operation of a parasitic SCR (silicon control 
rectifier), triggered by ionizing radiation. In the area of latch-up, 
the chip can be made inherently hard due to use of the Epitaxial 
process for fabrication of the base layer. Even the use of an 
Epitaxial layer does not guarantee complete freedom from latch- 
up, however. The next step generally involves a silicon on insulator 
(SOT) or Silicon on Sapphire (SOS) approach, where the substrate 
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is totally insulated, and latch-ups are not possible. This is an 
expensive approach, 


In some cases, shielding is effective, because even a few 
millimeters of aluminum can stop electrons and protons. However, 
with highly energetic or massive particles (such as alpha particles, 
helium nuclei), shielding can be counter-productive. When the 
atoms in the shielding are hit by an energetic particle, a cascade of 
lower energy, lower mass particles results. These can cause as 
much or more damage than the original source particle. 


Cumulative dose and single events 


The more radiation that the equipment gets, in low does for a long 
time, or in high does for a shorter time, the greater the probability 
of damage. The Total Ionization Dose (TID) accumulates over 
time, and actually displaces the semiconductor lattice structure. It 
causes shifts in the threshold voltage device, and noticeable 
increased current draw. The damage can become permanent. TID 
isn't the major concern, as devices become smaller, and the oxide 
gates become thinner, as technology advances. The higher the 
voltage, though, the more problematic the effect can be. Analog to 
digital converters can experience conversions shifts. 


These events are caused by high energy particles, usually protons, 
that disrupt and damage the semiconductor lattice. The effects can 
be upsets (bit changes) or latch-ups (bit stuck). The damage can 
“heal” itself, but its often permanent. Most of the problems are 
caused by energetic solar protons, although galactic cosmic rays 
are also an issue. Solar activity varies, but is now monitored by 
sentinel spacecraft, and periods of intensive solar radiation and 
particle flux can be predicted. Although the Sun is only 8 light 
minutes away from Earth, the energetic particles travel much 
slower than light, and we have several days warning. During 
periods of intense solar activity, Coronal Mass Ejection (CME) 
events can send massive streams of charged particles outward. 
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These hit the Earth’s magnetic field and create a bow wave. The 
Aurora Borealis or Northern Lights are one manifestation of 
incoming charged particles hitting the upper reaches of the 
ionosphere. 


Cosmic rays, particles and electromagnetic radiation, are omni- 
directional, and come from extra-solar sources. Most of them, 
85%, are protons, with gamma rays and x-rays thrown in the mix. 
Energy levels range to 10° to 10° electron volts (eV). These are 
mostly filtered out by Earth’s atmosphere. There is no such 
mechanism on the Moon, where they reach and interact with the 
surface material. Solar flux energy's range to several Billion 
electron volts (Gev). 


The effects of radiation on silicon circuits can be mitigated by 
redundancy, the use of specifically radiation hardened parts, Error 
Detection and Correction (EDAC) circuitry, and scrubbing 
techniques. Hardened chips are produced on special insulating 
substrates such as Sapphire. The technology is called silicon on 
insulator (SOI). Bipolar technology chips can withstand radiation 
better than CMOS technology chips, at the cost of greatly 
increased power consumption. Shielding techniques can also be 
applied. Radiation hardened parts are much more expensive than 
standard parts. 


Single Event Upsets (SEU) are instantaneous events, caused by 
highly energetic particles such as Cosmic Rays. This causes 
momentary bit flips, but is generally not cumulative. Some events 
may require a reset to affect recovery of state. 


Mitigation Techniques 
The effects of radiation on silicon circuits can be mitigated by 
redundancy, the use of specifically radiation hardened parts, Error 


Detection and Correction (EDAC) circuitry, and scrubbing 
techniques. Hardened chips are produced on special insulating 
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substrates such as Sapphire. Bipolar technology chips can 
withstand radiation better than CMOS technology chips, at the cost 
of greatly increased power consumption. Shielding techniques are 
also applied. In error detection and correction techniques, special 
encoding of the stored information provides a protection against 
flipped bits, at the cost of additional bits to store. Redundancy can 
also be applied at the device or box level, with the popular Triple 
Modular Redundancy (TMR) technique triplicating everything, 
and based on the assumption that the probability of a double failure 
is less than that of a single failure. Watchdog timers are used to 
reset systems unless they are themselves reset by the software. Of 
course, the watchdog timer circuitry is also susceptible to failure. 


We can deal with the radiation environment, but it does make the 
electronics more expensive. 


One concept that is easily implemented, and addresses the 
radiation damage issue, is called Rad Hard software. This is a 
series of software routines that run in the background on the main 
flight computer, or a dedicated computer, and check for the signs 
of radiation damage. The best indicator is an increase in current 
draw. The flight cpu must monitor and trend it's current draw, and 
take critical action such as a reboot if it deems necessary. The Rad 
Hard software is a variation on self-check routines, but with the 
ability to take action if needed. We can keep tabs on memory by 
conducting CRC (cyclic redundancy checks), and one approach to 
mitigating damage to semiconductor memory is “scrubbing,” 
where we read and write back each memory locations (being 
careful not to interfere with ongoing operations). This can be done 
by a background task that is the lowest priority in the system. 
Watchdog timers are also useful in getting out of a situation such 
as the Priority Inversion, or just a radiation-induced bit flip. There 
should be a pre-defined safe mode for the computer as well. Key 
state data from just before the fault should be available to the 
control center. Unused portions of memory can be filled with bit 
patterns that can be monitored for changes. We must be certain that 
all of the unused interrupt vectors point to a safe area in the code. 
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There is a lot of creative work to be done in this area. 
Mobility Platform 


What platform do we need for sub-surface exploration? The Earth- 
based volcano explorer used wheels. Legs are possible, but present 
a higher difficulty is control. NASA worked with a tetrahedral 
explorer as a mobility platform. A snake-like crawler? More 
hands-on work needs to be done in terrestrial lava caves to get a 
good combination of mobility, stability, and low power 
consumption. At the moment, a robot derived from a Mars Rover 
design, from NASA Ames is exploring in Caves in Oregon. 


Methods of Underground Navigation 


Navigation in a structured environment is not a challenge. It's the 
real world that's a problem. A telerobot operates in a three- 
dimensional world, as do we. If they are not fixed units, we need to 
measure a workspace's invariant's, the dimensions, axes, possible 
navigation and reference points. A mobile robot can use dead 
reckoning or a beacon-based navigation. This works well on Earth, 
where we have navigation grid infrastructure such as GPS, but 
doesn't work on Mars. And Mars has no usable magnetic field. A 
key consideration for navigation is the choice of a coordinate 
system. For hundreds of years, Earth has had a well-defined 
latitude/longitude grid. There will be similar system set up for the 
Moon, and Mars. Navigation becomes obstacle avoidance when 
done up close. 


Communications 


Communications can be via a tether, or radio. A tether is handy to 
supply power as well, but is a nuisance due to getting snagged. 
Radio communications is a problem is there are numerous twists 
and turns n the path. Radio relays might be used, with the explorer 
dropping them as needed. Very low frequency radio has been 
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shown to work through rock. 


The CCSDS, Consultative Committee on Space Data Standards, 
has evolved a delay tolerant protocol for use in space. A concept 
called the Interplanetary Internet uses a store-and-forward node in 
orbit around a planet (initially, Mars) that would burst-transmit 
data back to Earth during available communications windows. At 
certain times, when the geometry is right, the Mars bound traffic 
might encounter significant interference. Mars surface craft 
communicate to Orbiters, which relay the transmissions to Earth. 
This allows for a lower wattage transmitter on the surface vehicle. 
Mars does not (yet) have the full infrastructure that is currently in 
place around the Earth — a network of navigation, weather, and 
communications satellites. 


The Cubesat Space Protocol is a network layer protocol, 
specifically for Cubesats, released in 2010 It features a 32-bit 
header with both network layer and transport layer data. It is 
written in the c language, and works with linux and FreeRTOS. 
The protocol and its implementation is Open source. At the 
physical layer, the protocol supports CAN bus, I2C, RS-232, 
TCP/IP, and CCDSDS space link protocol. 


In space, we can use FTP over CCSDS, but watch those NAK’s. 
When you send a packet and receive a negative acknowledgment 
(NAK), you usually resend. Too many negative acknowledgments 
can overload the capacity of the link. There is a defined and 
Interplanetary Internet, which address long delays and major error 
sources. It uses store-and-forward (like the Internet) nodes in orbit 
around a planet., such as Mars. It uses burst transmission back to 
Earth. It is a bundle protocol, and assumes a high probability of 
errors and a non-continuous link. This is a JPL Project. 


For communication with units underground, extremely low 
frequency systems work, if the depth is not too great. Explorer 
units could drop relay units from their entry point, as they go 
along, but there necessarily a limit to the number of these that 
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could be included. 
PiSat 


The PiSat is an open source NASA/GSFC design for a “Distributed 
Mission Test Platform.” It represents an ideal platform for 
prototyping Cubesat Flight software, as well as educational 
outreach. The PiSat defines the flight computer architecture 
(ARM), a sensor suite, the enclosure and battery, and the Flight 
Software. It was developed by NASA/GSFC Code 582, with IRAD 
funding. It was developed with help from undergraduate student 
interns. 


The Flight Computer of choice is the Raspberry Pi (2 B+), based 
on the ARM architecture, and running the linux operating system 
or RTOS, with Code 582's Core Flight System software suite. The 
supported sensors include a GPS module, magnetometer, compass, 
accelerometer, a high definition camera, A/D converters, and a 
real-time clock. Data storage is provided by an SD flash memory 
card. It uses the Xbee peer-to-peer wireless communication. The 
price of the hardware components comes in around $350, including 
the printed enclosure. 


Cubesats accept the PC-104 board standard (90 mm x 96 mm), and 
the boards are stackable. There is no requirement to use this size 
board, or the standard, but there can be advantages, such as 
availability of interfaces. 


The CFS software will be discussed in detail in the Software 
section of this document, but we will say here that it is reusable 
mission software that has already flown on many NASA missions, 
including the Lunar Reconnaissance Orbiter, and covers common 
onboard tasks. A collection of applications under the CFS includes 
uplink and downlink of data, attitude calculation, and support of 
the camera. There are a set of scripts for startup and shutdown of 
the system. For test or operations, there are several software 
choices, including the COSMOS system from Ball Aerospace. The 
unit is powered via USB during test and development, and by a 
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standard lithium battery for flight. 


An intern (and student of the author) integrated an ocean 
spectrometer into the PiSat architecture at GSFC. 


Cube-X housekeeping tasks 


Besides position determination and navigation, the onboard 
embedded systems has a variety of housekeeping tasks to attend to. 
Generally, there is a dedicated unit, sometimes referred to as the 
Command & Data Handler (C&DH) with interfaces with the 
spacecraft transmitters and receivers, the onboard data system, and 
the flight computer. The C&DH, itself a computer, is in charge of 
uplinked data (generally, commands), onboard data storage, and 
data transmission. The C&DH can send received commands 
directly to various spacecraft components, or can hold them for 
later dissemination at a specified time. The C&DH has a direct 
connection with the science instrument(s) for that data stream. If 
the science instrument package has multiple sensors, there may be 
a separate science C&DH (SC&DH) that consolidates the sensed 
data, and hands it over to the C&DH for transmission to the 
ground. The C&DH can forward all commands related to science 
instruments to the IC&DH. 


The spacecraft computer calculates and maintains a table of 
consumables data, both value and usage rate. This includes 
available electrical power in the batteries, state-of-charge, the 
amount of thruster propellant remaining, and the status of any 
other renewable or consumable asset. This is periodically 
telemetered to the ground. Over the long term, we can do trending 
on this data, which can help us identify pending problems. 


The spacecraft electronics needs to be kept within a certain 
temperature for proper operation. Generally, the only heat source is 
the Sun, and the only heat sink is deep space. There are options as 
to how the spacecraft can be oriented. In close orbit to a planet, the 
planet may also represent a heat source. Automatic thermal louvers 
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can be used to regulate the spacecraft internal temperature, if they 
are pointed to deep space. The flight computer's job is to keep the 
science instrument or communications antennae pointed in the 
right direction. This might be overridden in case the spacecraft is 
getting too hot or too cold. 


The computer needs to know the state-of-charge (SOC) of the 
batteries at all times, and whether current is flowing into or out of 
the batteries. It the SOC is getting too low, some operations must 
be suspended, so the solar panels or spacecraft itself can be re- 
oriented to maximize charging. In some cases, redundant 
equipment may be turned off, according to a predetermined 
electrical load-shedding algorithm. If the batteries are fully 
discharged, it is generally the end of the mission, because pointing 
to the Sun cannot be achieved, except by lucky accident. Don't bet 
on it. If you're underground, you have a bigger problem. 


Open Source 


This is a topic we need to discuss before we get into software. It is 
not a technical topic, but concerns your right to use (and/or own, 
modify) software. It’s those software licenses you click to agree 
with, and never read. That’s what the intellectual property lawyers 
are betting on. 


Software and software tools are available in proprietary and open 
source versions. Open source software is free and widely available, 
and may be incorporated into your system. It is available under 
license, which generally says that you can use it, but derivative 
products must be made available under the same license. This 
presents a problem if it is mixed with purchased, licensed 
commercial software, or a level of exclusivity is required. Major 
government agencies such as the Department of Defense and 
NASA have policies related to the use of Open Source software. 

Adapting a commercial or open source operating system to a 
particular problem domain can be tricky. Usually, the commercial 
operating systems need to be used “as-is” and the source code is 
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not available. The software can usually be configured between 
well-defined limits, but there will be no visibility of the internal 
workings. For the open source situation, there will be a multitude 
of source code modules and libraries that can be configured and 
customized, but the process is complex. The user can also write 
new modules in this case. 


Large corporations or government agencies sometimes have 
problems incorporating open source products into their projects. 
Open Source did not fit the model of how they have done business 
traditionally. They are issues and lingering doubts. Many Federal 
agencies have developed Open Source policies. NASA has created 
an open source license, the NASA Open Source Agreement 
(NOSA), to address these issues. 


It has released software under this license, but the Free Software 
Foundation had some issues with the terms of the license. The 
Open Source Initiative (OpenSource.org) maintains the definition 
of Open Source, and certifies licenses such as the NOSA. 
(HTTP://opensource.org/licenses/NASA-1.3) The GNU General 
Public License (GPL) is the most widely used free software 
license. It guarantees end users the freedoms to use, study, share, 
copy, and modify the software. Software that ensures that these 
rights are retained is called free software. The license was 
originally written by Richard Stallman of the Free Software 
Foundation (FSF) for the GNU project in 1989. The GPL is a 
copyleft license, which means that derived works can only be 
distributed under the same license terms. This is in distinction to 
permissive free software licenses, of which the BSD licenses are 
the standard examples. Copyleft is in counterpoint to traditional 
copyright. Proprietary software “poisons” free software, and 
cannot be included or integrated with it, without abandoning the 
GPL. The GPL covers the GNU/linux operating systems and most 
of the GNU/linux-based applications. 


A Vendor’s software tools and operating system or application 
code is usually proprietary intellectual property. It is unusual to get 
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the source code to examine, at least without binding legal 
documents and additional funds. Along with this, you do get the 
vendor support. An alternative is open source code, which is in the 
public domain. There are a series of licenses covering open source 
code usage, including the Creative Commons License, the gnu 
public license, copyleft, and others. Open Source describes a 
collaborative environment for development and testing. Use of 
open source code carries with it an implied responsibility to “pay 
back” to the community. Open Source is not necessarily free. 


The Open source philosophy is sometimes at odds with the 
rigidized procedures evolved to ensure software performance and 
reliability. Offsetting this is the increased visibility into the 
internals of the software packages, and control over the entire 
software package. Besides application code, operating systems 
such as GNU/linux and bsd can be open source. The programming 
language Python is open source. The popular web server Apache is 
also open source, as is the database code, MySQL, or SQLite. 


A list of open source tools for Cubesats and Rovers can be found 
here: 


http://wiki.developspace.net/Open_ Source Engineering Tools 


Onboard Software 


Flight s/w is a special case of embedded software. As such, it is 
generally more difficult to design, implement, and test. It must be 
treated carefully, because most of the Cubesat functionality will 
rely on software, and the mission success will be directly related to 
software. 


Flight Software can be proprietary or Open Source, but almost all 
Cubesat onboard software is open source. 


FSW has several distinguishing characteristics: 


e There are no direct user interfaces such as monitor and 
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keyboard. All interactions are through uplink and downlink. 


e It interfaces with numerous hardware devices such as 
science instruments and sensors 


e It executes on _ radiation-hardened processors and 
microcontrollers that are relatively slow and memory- 
limited. 


e It performs real-time processing. It must satisfy numerous 
timing constraints (timed commands, periodic deadlines, 
async event response). Being late = being wrong. 


e Besides attitude determination and control, the onboard 
embedded systems has a variety of housekeeping tasks to 
attend to. 


NASA's Core Flight Executive, and Core Flight 
Software 


The Core Flight Executive, from the Flight Software Branch at 
NASA/GSFC, is an open source operating system framework. The 
executive is a set of mission independent reusable software 
services and an operating environment. Within this architecture, 
various mission-specific applications can be hosted. The cFE 
focuses on the commonality of flight software. The Core Flight 
System (CFS) supplies libraries and applications. Much flight 
software legacy went into the concept of the cFE. It has gotten 
traction within the Goddard community, and is in use on many 
flight projects, simulators, and test beds (FlatSats) at multiple 
NASA centers, as well as functioning in on-orbit Cubesat. The 
second application using the Goddard software was a drone 
project. 


The cFE presents a layered architecture, starting with the bootstrap 
process, and including a real time operating system. At this level, a 
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board support package is needed for the particular hardware in use. 
Many of these have been developed. At the OS abstraction level, a 
Platform support package is included. The cFE core comes next, 
with cFE libraries and specific mission libraries. Ap's habituate the 
Sin, or upper layer. The cFE strives to provide a platform and 
project independent run time environment. 


The boot process involves software to get things going after 
power-on, and is contained in non-volatile memory. cFE has boot 
loaders for the ARM, and other popular flight architectures. The 
real time operating systems can be any of a number of different 
open source or proprietary products, VxWorks and RTEMS for 
example. This layer provides interrupt handling, a scheduler, a file 
system, and interprocess communication. 


The Platform Support Package is an abstraction layer that allows 
the cFE to run a particular RTOS on a particular hardware 
platform. There is a PSP for desktop pc's for the cFE. The cFE 
Core includes a set of re-usable, mission independent services. It 
presents a standardized Application Program Interface (API) to the 
programmer. A software bus architecture is provided for messaging 
between applications. 


The Event services at the core level provides an interface to send 
asynchronous messages, telemetry. The cFE also provides time 
services. 


Aps include a Health and Safety Ap with a watchdog. A 
housekeeping AP for messages with the ground, data storage and 
file manager aps, a memory checker, a stored command processor, 
a scheduler, a check-summer, and a memory manager. Aps can be 
developed and added to the library with ease. 


A recent NASA/GSFC Cubesat project uses a FPGA-based system 
on a chip architecture with Linux and the cFE. CFE and its 
associated cFS are available as an architecture for Cubesats in 
general. 


2T 


The cFE has been released into the World-Wide Open Source 
community, and has found many applications outside of NASA. 


NASA's Software Architecture Review Board reviewed the cFE in 
2011. They found it a well thought-out product that definitely met 
a NASA need. It was also seen to have the potential of becoming a 
dominant flight software architectural framework. The technology 
was seen to be mature. 


The cFS is the core flight software, a series of aps for generally 
useful tasks onboard the spacecraft. The cFS is a platform and 
project independent reusable software framework and set of 
reusable applications. This framework is used as the basis for the 
flight software for satellite data systems and instruments, but can 
be used on other embedded systems in general. More information 
on the cFS can be found at http://cfs.gsfc.nasa.gov/OSAL 


The OS Abstraction Layer (OSAL) project is a small software 
library that isolates the embedded software from the real time 
operating system. The OSAL provides an Application Program 
Interface (API) to an abstract real time operating system. This 
provides a way to develop one set of embedded application code 
that is independent of the operating system being used. It is a form 
of middleware. 

cFS aps 


CFS aps are core Flight System (cFS) applications that are plug- 
in's to the Core Flight Executive (CFE) component. Some of these 
are discussed below. 


CCSDS File Delivery (CF) 


The CF application is used for transmitting and receiving files. To 
transfer files using CFDP, the CF application must communicate 
with a CFDP-compliant peer. CF sends and receives file 
information and file-data in Protocol Data Units (PDUs) that are 
compliant with the CFDP standard protocol defined in the CCSDS 


28 


727.0-B-4 Blue Book. The PDUs are transferred to and from the 
CF application via CCSDS packets on the cFE's software bus 
middleware. 


Limit check (LC) 


The LC application monitors telemetry data points in a cFS system 
and compares the values against predefined threshold limits. When 
a threshold condition is encountered, an event message is issued 
and a Relative Time Sequence (RTS) command script may be 
initiated to respond/react to the threshold violation. 


Checksum (CS) 


The CS application is used for for ensuring the integrity of onboard 
memory. CS calculates Cyclic Redundancy Checks (CRCs) on the 
different memory regions and compares the CRC values with a 
baseline value calculated at system start up. CS has the ability to 
ensure the integrity of cFE applications, cFE tables, the cFE core, 
the onboard operating system (OS), onboard EEPROM, as well as, 
any memory regions ("Memory") specified by the users. 


Stored Command (SC) 


The SC application allows a system to be autonomously 
commanded 24 hours a day using sequences of commands that are 
loaded to SC. Each command has a time tag associated with it, 
permitting the command to be released for distribution at 
predetermined times. SC supports both Absolute Time tagged 
command Sequences (ATSs) as well as multiple Relative Time 
tagged command Sequences (RTSs). 


Scheduler (SCH) 
The SCH application provides a method of generating software bus 


messages at predetermined timing intervals. This allows the system 
to operate in a Time Division Multiplexed (TDM) fashion with 
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deterministic behavior. The TDM major frame is defined by the 
Major Time Synchronization Signal used by the cFE TIME 
Services (typically 1 Hz). The Minor Frame timing (number of 
slots executed within each Major Frame) is also configurable. 


File Manager (FM) 


The FM application provides onboard file system management 
services by processing ground commands for copying, moving, 
and renaming files, decompressing files, creating directories, 
deleting files and directories, providing file and directory 
informational telemetry messages, and providing open file and 
directory listings. The FM requires use of the cFS application 
library. 


OpSys 


An operating system (OS) is a software program that manages 
computer hardware and software resources, and provides common 
services for execution of various application programs. Without an 
operating system, a user cannot run an application program on 
their computer, unless the application program is itself self- 
booting, and has an initiation module, that does the necessary 
hardware set-up. 


For hardware functions such as input, output, and memory 
allocation, the operating system acts as an intermediary between 
application programs and the computer hardware, although the 
application code is usually executed directly by the hardware and 
will frequently call the OS or be interrupted by it. Operating 
systems are found on almost any device that contains a computer. 
The operating system functions need to be addressed by software 
(or possibly hardware), even if there is no entity that we can point 
to, called the Operating System. In simple, usually single-task 
programs, there might not be an operating system per se, but the 
functionality is still part of the overall software. 
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An operating system manages computer resources, including: 


Memory. 

T/O. 

Interrupts. 
Tasks/processes/application programs. 
File system 

clock. 


The operating system arbitrates and enforces priorities. If there are 
not multiple software entities to arbitrate among, the job is simpler. 
An operating system can be off-the-shelf commercial or open 
source code, or the application software developer can decide to 
build his or her own. To avoid unnecessary reinvention of the 
wheel an available product is usually chosen. Operating systems 
are usually large and complex pieces of software. This is because 
they have to be generic in function, as the originator does not know 
what application space it will be used in. Operating systems for 
desktop/network/server application are usually not applicable for 
embedded applications. Mostly they are too large, having many 
components that will not be needed (such as the human interface), 
and they do not address the real-time requirements of the 
embedded domain. 


Adapting a commercial or open source operating system to a 
particular embedded domain can be tricky. Usually, the 
commercial operating systems need to be used “as-is” and the 
source code is not available. The software can usually be 
configured between well-defined limits, but there will be no 
visibility of the internal workings. For the open source situation, 
there will be a multitude of source code modules and libraries that 
can be configured and customized, but the process is complex. The 
user can also write new modules in this case. 


Operating Systems designed for the desktop are not well suited for 
embedded These were developed under the assumption that 
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whatever memory is required will be available, and real-time 
operation with hard deadlines is not required. 


Real-time operating systems, as opposed to those addressing 
desktop, tablet, and server applications, emphasize predictability 
and consistency rather than throughput and low latencies. 
Determinism is probably the most important feature in a real-time 
operating system. 


A microkernel operating system is ideally suited to embedded 
systems. It is slimmed down to include only those features needed, 
with no additional code. Barebones is the term sometimes used. 
The microkernel handles memory management, threads, and 
communication between processes. It has device drivers for only 
those devices present. The operating systems may have to be 
recompiled when new devices are added. A file system, if required, 
is run in user space. MINIX, as an example of a streamlined 
kernel, with about 6,000 lines of code. 


For computer systems like the Raspberry Pi, there are enough 
resources to run an operating system — in fact, it runs Linux. But 
linux is NOT a real time operating system. It can be patched to 
operate better in real-time applications, or a custom open source 
product such as FreeRTOS can be used. 


For Arduino-based boards, the architecture is just getting 
sophisticated enough to run an operating system. In many cases, an 
operating system is not needed. Keep in mind, that some operating 
system functions still need to be implemented. Setting up the 
interrupt vectors at initialization is an example. The tasks that the 
computer has to do might be simple enough that a simple software 
loop architecture can do the job, perhaps with interrupts. 

File Systems 


Use of an industry-standard file system will ease the interface to 
ground based storage and processing. There are several popular file 
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systems, usually defined as part of a specific operating system. A 
file system provides a way to organized your data, and file systems 
management services are part of the operating system. The 
operating systems may support several file formats. A file system 
organizes data. It presents a data-centric view of a digital storage 
system. 


A file is a container of information, usually stored as a one- 
dimensional array of bytes. Historically, the file format and the 
nature of the file system were driven by the mechanism of data 
storage. On early computer tape units for mainframes, the access 
mechanism was serial, leading to long access times. With disk and 
solid-state storage, the access time is vastly improved, as the 
device is random access — the same access time applies for any 
data item. 


Metadata includes information about the data in a file. This 
consists of the file name and type, and other parameters such as the 
size, date and time of creation, the data and time of last access, the 
owner and read/write/access permissions, when a backup was last 
made, and other related information. 


A directory, like the manila file folder, is a special file that points 
to (“contains”) other files. This allows files to be organized, and 
implements a hierarchical file system. 


There are many file system standards. The Microsoft operating 
systems support the FAT and NTFS file systems among others. The 
FAT (File Allocation System) format originated with early support 
of 8-bit microprocessor systems with MS-DOS. Fat-12 and FAT-16 
had restrictions on the number of files in the root file system, but 
this has largely been removed with the introduction of FAT-32. File 
names are restricted to 8 characters, with a 3-character type 
specifier, the 8.3 format for file names. There are plenty of choices; 
don't re-invent the wheel. 


Attitude determination 
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For the Cube-x, attitude determination is simplified over the on- 
orbit case. Since the Cube-x will be in touch with the surface, it 
really only needs to avoid tipping over, which may be fatal, and 
falling into a hole. 


Position determination 


Position determination on the surface cannot rely on magnetic field 
since they are almost non-existent for the Lunar and Martian cases. 
There is no equivalent of GPS either. Navigation will be conducted 
by dead-reckoning along a pre-determined path based on orbiters' 
views. (LRO for the Moon, MRO for Mars). Local navigation, 
obstacle avoidance will be done optically. The current versions of 
the Raspberry Pi, for example, include a dedicated image 
processing engines, that can provide real time detection of drop- 
offs and obstacles. 


Electrical Power 


Electrical power is a critical resource. The power system of the 
spacecraft will consist of batteries, solar cells for recharging, and a 
charge regulator. In Earth orbit, the spacecraft is constantly moving 
from full sun to Earth shadow each orbit. Sometimes, the available 
energy in the batteries must be taken into account when planning 
operations. Big power users are RF transmission, and onboard 
computation. Some lighting must be provided for local navigation, 
and for the optical scanners. 


The latest generation of triple junction solar cells achieve up to 
30% efficiency in converting light to electrical power. The latest 
lithium-ion batteries are around 200 watt-hours per kilogram. 


A peak power tracker circuit serves as a “transformer” or 
impedance matcher between the solar arrays and the 
batteries/electrical loads, adjusting the impedance load the arrays 
“sees” for optimum transfer of power. It is a dc/dc stepdown 
converter. 
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Since the Lava Tube explorers will, by definition, be operating 
underground , the opportunity for recharging is not available. The 
battery's have to be sized to allow sufficient operating time. We 
might also envision a dedicated charger Cube-X that can recharge 
or recover and tow the Explorer Cube-X. 


Thermal issues 


The interior of the lava tubes should have a stable temperature. On 
Earth, caves assume the average yearly outside temperature for 
their location. It will possibly be warmer than the planetary 
surface, depending on volcanic activity. The rover will monitor 
ambient temperature as part of its tasks. It will require sufficient 
insulation and “waste” heat capture to continue operation for the 
duration of its mission. For the Greenland Rover Project, we used 
“waste” heat from the electronics to warm the battery's. 


Volcano Explorer 


The Robotics Group at Carnegie-Mellon University is headed by 
the famed Red Whittaker, who lead the CMU team to win the 
DARPA Challenge. He is also headed the team focused on the 
Google Lunar X Prize. One of his many projects was a mobile 
platform, Dante, designed to enter an active volcano. 


In December of 1992, Dante and his support team ventured to 
active Mount Erebus in Antarctica, 12,450 feet high, and about 800 
miles from the pole. Erebus is important enough that manned 
attempts were made to enter the caldera, all unsuccessful. How 
much the volcano contributes to the hole in the ozone layer above 
Antarctica is not known. The ozone layer blocks ultraviolet light 
from the sun, and is critical to the continuance of life on Earth. The 
robot made the descent to the crater floor, some 850 feet from the 
top. Here it took temperature measurements, and gas samples. 
Erebus tends to erupt in a minor fashion several times a day. This 
was a NASA Project, supported by the National Science 
Foundation. The temperature proved to be around 1,100 degrees 
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from the corrosive gases vented by the volcano. 


Dante is a six-legged walking robot, weighing close to 1000 
pounds, and connected to the support team outside the volcano by 
a tether to provide power and data, and possible retrieval if the 
robot becomes disabled. 


In August of 1994, an upgraded version of the robot, Dante 2, 
explored the active Alaskan volcano, Mount Spurr. This is located 
some 80 miles west of Anchorage. The descent into the caldera 
was 650 feet. The robot was monitored from a control facility in 
Anchorage, via a satellite link, providing a live video feed.. Dante- 
2 was bulked up at 1,700 pounds, having been redesigned based on 
the earlier robot's lessons-learned. It was able to explore 
underneath a rock ledge, that had blocked an aerial view of a part 
of the crater. After successfully completing its mission, the robot 
walked its way out of the crater. 


CMU Rovers have also been used in abandoned mine mapping. A 
rover called Groundhog went into an abandoned Pennsylvania coal 
mine and sent out live video to a conference on Mine Safety in 
2002. They primary usage for the robots is seen as mapping. After 
initial tests, the concept of a wheeled rover was reconsidered, and 
an amphibious robot was designed. This is because old mines 
shafts are frequently flooded. 


Once a lava tube is entered, the robotic vehicle must operate 
autonomously, due to the lack of a communications link. We might 
consider radio relays withing the tube, but this gets complex fairly 
quickly. 


Communication 
Communication from within the lava tube to the opening will be 


problematic. The explorer rover will not be in line of sight to the 
opening of the tube, except briefly. Two approaches come to mind. 
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The explorer could trail a cable, but this has the potential to snagg 
and trap the explorer. Another approach would be to drop repeater 
stations along the way. This addresses both distance, and blocking 
scenario's. It will be important for the explorer to retain all 
observation data, augmented with meta-data such as distance 
traveled and time, so that it can be potentially recovered with the 
data intact. This might drive a requirement for a recovery Rover. 


An approach to exploring Lunar Lava Tubes with Cube- 
Xs. 


This section discusses an approach that evolved at a summer 
session of undergraduate and graduate students that the author 
mentored. It was a cubesat-based program, so naturally the lava 
tube explorer was cubesat-based. This is not a problem, as the 
Cubesat specification merely presents a standard architecture. We 
can use them in orbit for communications relay, on a lander 
vehicle/operations base, and as explorers, with a mobility platform. 


The project addressed a fixed base on the lunar surface, with a 
mothership/carrier that served as a recharging station and data 
assembler and forwarder. This unit communicated with an orbiting 
communications cubesat relay. The approach of using the cubesat 
architecture for all the elements allows for an economy of scale, 
and an overall reduction in complexity. The term Cube-X had not 
yet been applied. 


It also provides a commonality in architecture, and opens the 
possibility of implementation of a swarm-type cooperative 
behavior. 


Lunabotics Mining Challenge 


NASA's Mining Competition was established in 2010, and is 
ongoing. It challenges college students to apply system 
engineering principles to mining scenarios, and test the hardware 
in the Caterpillar Mining Area. Schedule, Budget, and Design 
Philosophy are parameters for judging. NASA also required K-12 
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outreach. There are a series of awards in different project areas. 
Quoting from the announcement, “The Lunabotics Mining 
Competition is a university level competition designed to engage 
and retain students in Science, Technology, Engineering and Math 
(STEM). NASA will directly benefit from the competition by 
encouraging the development of innovative lunar excavation 
concepts from universities which may result in clever ideas and 
solutions that could be applied to an actual lunar excavation device 
or payload. The challenge is for students to design and build a 
remote controlled or autonomous excavator (lunabot) that can 
collect and deposit a minimum of 10 kg of lunar dirt within 15 
minutes. The complexities of the challenge include the abrasive 
characteristics of the lunar surface, the weight and size limitations 
of the lunabot, and the ability to control the lunabot from a remote 
control center. Twenty two teams from around the nation are ready 
to compete at the Kennedy Space Center Astronaut Hall of Fame 
on May 27-28. These are annual events, with teams selected each 
year. 


“The challenge will be conducted in a head-to-head format, in 
which the teams will be required to perform a competition attempt 
using the regolith sandbox and collector provided by NASA. 
NASA will fill the sandbox with simulated regolith, compact it and 
place rocks in it. Each competition attempt will occur sequentially. 
Between each competition attempt, the rocks will be removed, the 
regolith will be returned to a compacted state and the rocks will be 
returned to the sandbox. Consideration of prize awards will be 
based on each team's performance during the official competition 
attempt. All excavated mass deposited in the collector during the 
competition attempt will be weighed after completion of the 
competition attempt. The teams that excavate the first, second and 
third most lunar regolith mass over the minimum excavation 
requirement within the time limit will respectively win first, 
second and third place prizes.” 


The Moon Diver mission wants to use JPL's AXEL extreme-terrain 
rover,. A good choice, as JPL is pretty much the go-to place for 
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rovers to explore other planets. The JPL Open Source Rover is a 
non-flight design. It is based on the highly successful Curiosity 
Rover. and uses a Raspberry Pi as a computer. It weighs about 25 
pounds, and can move up to 9.7 inches per second. It uses the 
suspension from Curiosity, and has 6-wheel steering. It is a non- 
flight unit, but incorporates a lot of good design and lessons 
learned from mars operation. 


Martian Lava Tubes 


The main source for lava tubes on the red planet is the majestic 
volcano, Olympus Mons. Sections have collapsed, and are visible 
from orbit. They may manifest as chains of craters. 


Some of the techniques for exploration and exploitation of lunar 
lava tubes can be applied on Mars. The Martian tubes are larger 
than those on the Moon, but smaller than those on Earth. The 
existance of Martian lava tubes have been known since the Viking 
Orbiter mission. The Caves of Mars Project considered lava tubes 
as well as some other natural formations. This would shield 
manned bases from solar radiation as well as winds and dust 
storms. 


The Caves of Mars Project was conducted in the early 2000's by 
the NASA Institute for Advanced Concepts. It was looking at 
infrastructure applicable to human habitation. Both caves and lava 
tubes would be ideal. They would provide radiation shielding and 
could be sealed off with airlocks. The temperature and atmospheric 
pressure could be maintained. There is the possibility of finding 
sources of underground water, as well as valuable minerals. 


The Mars Student Imaging Program by NASA and Arizona State 
University allows selected grade school students to do imaging 
using Mars Odyssey, in Martian orbit. Seventh graders from 
middle school in California discovered lava tubes, and there was 
one with a pit crater. This is essentially a skylight of the 
underground tube. 


In 2007, seven vertical shafts were imaged on Mars. These were 
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100-255 meters in diameter, and up to 130 meters in depth. Cave 
entrances are also known to exist. 


Lava tubes have an advantage in providing shielding from Mars 
surface radiation, mostly from the solar wind. There is no magnetic 
field to speak of, and a very thin atmosphere to provide an Earth- 
level protection. On the other hand, if any life has survived on 
Mars, it would most likely be in the underground dwellings. The 
caves, or lava tubes provide a protected living space that could be 
modified to support an Earth-level atmosphere, they would have 
mush less temperature variation. Martian caves may also be a 
source of water ice. They also offer protection from asteroid 
strikes, as the Martian atmosphere is too sparse to provide that. 
Mars is closer to the asteroid belt. There could be available 
subsurface thermal energy sources, and other useful resources that 
could be mined. 


Lava tubes may have one or more skylights, making entrance and 
exit, as well as sealing difficult. For exploration, a robotic system 
could winch a rover down into the tube, to conduct exploration. If 
we're lucky, we will find shallow horizontal tubes, with “drive-in 
entrances” that would later only require sealing with an airlock 
door. 


Some of the desired technologies would include inflatable cave 
liners, and spray-on liners like shotcrete, that could be made form 
local materials. 


Multiple rovers can be put into a lava tube for parallel exploration. 
We shall address a swarm architecture later in this book for lava 
tube exploration. 

Besides habitats, Martian Lava tubes may harbor Martian 
organisms. That would be interesting. 


Other Places 
At the moment, we do not have much evidence for lava tubes on 


other planets or their moons, except for Venus. Similar structure 
might exist on Jupiter and Saturn, and their moons, in the form of 
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ice volcanoes and dissolution caves. 


Ops Concept for Cube-X exploration of 
Martian Lava Tubes 


The Concept includes a mothership/transporter that can hold 
multiple explorers. This unit will provide data storage and 
forwarding, have the ability to provide electrical power. And will 
deploy and collect the underground rovers. The computing 
architecture of the deployer will follow the Cubesat architecture. 


The number of explorers can be determined from a trade study, but 
certainly can in the the neighborhood of a dozen. The deployer will 
have a deck that will hold two rows of explorers. This will 
preclude loss of mission of one explorer gets hung up. It is not 
intended that the explorers will be retrieved. All of the explorers 
will be checked for functionality before deployment, and will be 
deployed fully charged. The explorers will be identical units, excep 
for their sensor sets. 


One of the biggest challenges to operations is underground 
navigation and communications. For communication, an explorer 
could trail a communication line. This has the added ability to 
supply power. The problem is, snagging the line. The Explorer 
could also periodically drop off communications relays, and this 
would be usable if the tube has significant twists and turns. 


An even harder problem is underground navigation. GPS is not 
feasible in situ, and dead-reckoning is difficult. There are several 
approaches for subsurface navigation. These involve generating a 
magnetic field by the Explorer, and using an array of surface 
mounted antennae to sense the location. This is then transmitted 
back to the rover. Horizontal location is good, but determining 
depth is difficult. DARPA has a subsurface navigation program, 
which has achieved near GPS-level position determination, and 
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gives depth information as well. It involves placing a series of 
magnetic dipoles on the surface, and a magnetometer on the 
underground vehicle. The vehicle's computer can the determine the 
depth and topology. 


Central to the Cubesat concept is the standardization of the 
interface between the launch vehicle and the spacecraft, which 
allows developers to pool together for launch and so reduce costs 
and increase opportunities. 


The Cubesat approach has since been adopted by numerous 
universities and organizations around the globe, and to date has 
been used as the basis of 40 missions (as at the end of October 
2008) with many active projects in development. High schools 
and individuals are also pursuing Cubesat projects. The launch cost 
is a major issue, but multiple Cubesats can be carried as secondary 
payloads on military and commercial flights. You don't get your 
choice of orbit, but you can get close. 


Since the initial proposal of the concept, further efforts have been 
made to define internal and external interfaces made by various 
developers of Cubesat subsystems, products and services that have 
defined the Cubesat 'standard' as it is today. A core strength of the 
Cubesat is its recognition of the need for flexibility in the 
definition of standards, and since conception the standard has 
evolved to ensure that these design rules are as open as possible. 
The most significant of these further advances in definition have 
been for the POD systems (in order to meet launch requirements) 
and the modularization of the internal electronics. 


The in-orbit success rate of university-led Cubesat projects (not 
withstanding launch failures) is around 50%; this is an 
understandable result of using the Cubesat as an education tool, 
where development itself is a learning process and in-orbit failure 
is a disappointment but should not be considered the primary 
focus. For projects involving significant participation of companies 
with experience in satellite development, all but one were a 
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success and demonstrated the strength of the Cubesat for non- 
educational applications. It is estimated that at least 12 Cubesat 
missions could be considered to have demonstrated significant 
successful in-orbit operations for a sustained period. All Cubesats 
missions to date may be considered to have had technological 
objectives to some degree, be it the demonstration of devices and 
system architectures developed in-house, or demonstration of Non- 
Space-Rated (NSR) Commercial-Off-The-Shelf | (COTS) 
component performance. Some Cubesats have also attempted to 
fulfill other mission objectives, although categorizing these 
accurately can be difficult Cube rover 


In the same sense that the standardized Cubesat revolutionized 
small satellite architecture, the Cube-X is attempting the same for 
space robots. It is a standardized modular planetary rover, such as 
the CubeRover developed by Astrobotic Technology. The first unit 
is slated to be on the lunar surface in 2020. Following the Cubesat 
concept of standardization and open source, the rovers leverage 
existing technology. This will result in an ecosystem of 
standardized architectures that allow the researcher to focus on the 
science. 


More importantly, the Mothership/lander will be a fixed base of 
operations, and will have the computational horse power to supply 
results, not just raw data. As we will suggest a little later on, 
multiple Cubesat or Cube-X units can be organized and managed 
as a swarm. 


Complexity in a system generally derives from two parameters, the 
number of units, and the number of interactions. So a swarm of 
cubesats can be said to be complex, compared to a single unit. This 
is somewhat balanced by the relative simplicity of the units, and 
their flexibility and redundancy. 


The author challenged students in a summer session to apply the 


Cubesat architecture as the basis of a lunar mission. This was to 
involve a lander, an orbiting relay satellite, with multiple mini- 
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rovers. The wheeled rovers would return to their “mothership” to 
ride out the lunar 2-week night, and explore during the day. The 
compute and data system architecture of the lander would be 
Cubesat based. There was a planned Cubesat in Lunar halo orbit 
to relay data, as the mission was baselined for the lunar backside. 


The student team designed and built the rover, and paired it with 
the satellite control center software, Cosmos, from Ball Brothers. It 
was tested at the Robotics facility of the National Institutes of 
Standards and Technology, and was found to operate as desired. 


Clusters 


In computing, a cluster means a group of loosely coupled elements, 
working together on the same goals. If the cluster were more 
tightly coupled, and self-directed, we'd have a swarm. As it is, we 
have a group of individuals that could be considered a single entity. 
Generally, members of a compute cluster have the same hardware 
and software configuration. One issue in clustering is the degree of 
coupling between elements. No coupling means we have a mob. A 
lot of coupling and we might have a swarm. In a cluster, 
management of the cluster itself can be centralized in a control 
unit, or can itself be distributed across the cluster. An example 
computer cluster is the NASA-developed Beowulf architecture. 


Swarms 


This section describes a different approach: collections of smaller 
co-operating systems that can combine their efforts and work as 
ad-hoc teams on problems of interest. Cubesats can be organized in 
Swarms. 


A intelligent swarm solution to resource exploration of the asteroid 
belt was proposed by Curtis, et al, in 2003. The concept of 
Cubesats was not advanced enough at the time for the authors to 
specifically mention them, and explored issues in local control, 
networking communications, and implementation in Open Source. 
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This is based on the collective or parallel behavior of 
homogeneous systems. This covers collective behavior, modeled 
on biological systems. Examples in nature include migrating birds, 
schooling fish, herding sheep and reindeer. A collective behavior 
emerges from interactions between members of the swarm, and the 
environment. The resources of the swarm are organized 
dynamically. 


Swarm behavior is based on the collective or parallel behavior of 
homogeneous systems. It is implemented as multiple co-operating 
software agents. This mimics collective behavior, modeled on 
biological systems. Examples in nature include migrating birds, 
schooling fish, and herding sheep. The resources of the swarm are 
organized dynamically. Swarm behavior is a group attribute across 
the swarm. It relies on continuous co-ordination of behavior. Each 
member makes stochastic choices. There is a lack of authority in 
the Swarm, each member making local choices based on local 
conditions, and a global rule set. Example rules are separation, 
avoid crowding; alignment, do what other swarm members are 
doing, and cohesion, move to the center of mass of the swarm. 
Swarm activity can be chaotic or orderly. Emergent, un-planned 
behaviors are seen in implemented systems. 


In Swarm systems, the key issues are communication between 
units, and cooperative behavior. The capability of individual units 
does not much matter; it is strength in numbers. Self-organizing 
behavior emerges from decentralized systems that interact both 
with members of the group, and the environment. Swarm 
intelligence is an emerging field, and swarm robotics is an active 
research topic. 

The Swarm will be agile, able to respond to targets of opportunity, 
when they arise. Flexibility, and the ability to respond locally to 
unplanned events will be part of the architecture. A Swarm is an 
implementation of a multi-agent system, where the agents are 
implemented in program code. 


Exploring lava tubes requires a diverse and agile system. Thus, a 
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swarm of robotic spacecraft with different capabilities might be 
used, combining into Teams of Convenience to address situations 
and issues discovered in situ. 


Biological swarms, such as ants, achieve success by division of 
labor throughout the swarm, collaboration, and sheer numbers. 
They have redundancy, as any individual can do any task assigned 
to the swarm. The individual units are highly autonomous, but are 
dependent on other members for their needs. They achieve success 
with a simple neural architecture and primitive communications. 


NASA did a lot of work in the 1970's and 1980's on ANTS — 
Autonomous Nano-Technology Swarm. The basic concepts were 
defined, but the implementation was not yet ready. Now, Cubesat- 
type architectures can address that. Actually, ANTS was preceded 
by a Project called BEES, Biologically Inspired Engineering for 
Exploration Systems, as an architecture. The overall concept is 
many small units working together, self-configuring, self-healing, 
making in-situ decisions. No direct human control, not per- 
programmed, but agile, making decisions on the spot. A reference 
mission to the Asteroid Belt was planned for 2020. Well, here we 
are, where's the mission? (This is partially addressed in the authors 
book, “A Cubesat Swarm Approach for Exploration of the 
Asteroid Belt, originally a student project that got to a high TRL). 
Another feature the swarm exhibits is teaming, social interaction 
between individual units. 


In Swarm robotics, the key issues are communication between 
units, and cooperative behavior. The capability of individual units 
nodes not much matter; it is the strength in numbers. Ants and 
other social insects such as termites, wasps, and bees, birds, fish, 
are models for swarm behavior. Self-organizing behavior emerges 
from decentralized systems that interact with members of the 
group, and the environment. Swarm intelligence is an emerging 
field, and swarm robotics is in its infancy. Co-operative behavior, 
enabled by software and intra-unit communications has been 
demonstrated. 
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We can postulate target selection according to mission goals, but 
also mention that mission goals change as data is collected at the 
site. The concept of multiple spacecraft/rovers coming together to 
form virtual instruments is discussed. Here, we might have 
simultaneous observations from multiple points. 


The Operational Concept involves teams that produce data and 
some higher level products, which are communicated to 
Messengers, and archived. The Rulers oversee data flow. When a 
sufficient amount is collected, a Messenger will be dispatched to 
carry it back to the mouth of the tube, to transmit the data to the 
controller. 


Today, the basis of Swarm technology is intelligent agents. An 
open source solution is HLL — High Level Logic. 
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Multi-rover support 


A satellite control center can handle a constellation, cluster, or 
swarm of multiple spacecraft. Examples include the GPS 
constellation, the weather satellite systems, TDRSS, and a number 
of commercial communications satellites, providing entertainment 
and data service world-wide. Constellations of communication 
satellites are used for commercial ventures such as DishNetwork, a 
satellite TV provider, and Iridium and GlobalStar, communications 
constellations. 


Complexity in a system generally derives from two parameters, the 
number of units, and the number of interactions. So a swarm of 
Cubesats Cube-X's can be considered complex, compared to a 
single unit. This is somewhat balanced by the relative simplicity of 
the units, and their flexibility and redundancy. 


An approach to Swarm control involves a hierarchy of a master 
control center and multiple assets to control, or a peer network of 
individual control centers, that also provides a built-in redundancy 
and backup. 


An ongoing debate in the optimum architecture for multi-unit 
control is between a centralized design, and a distributed 
architecture. Centralized is the legacy approach. 


The distributed architecture scales more freely, with computation, 
storage, and communications resources being added as demand 
increases. High system reliability and security can be maintained 
from industry best practices. The scale-able, distributed technology 
is driven by large data-centric organizations such as Google, and 
Amazon, as well as social media sites such as Facebook and 
Utube. These do not meet military-grade security, of course, but 
that can be addressed. 


Another advantage of the distributed approach is dynamic 
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allocation of resources, having (and paying for) resources when 
you need them, not all the time. The system provides mission 
safety simultaneously with cost effectiveness. Distributed 
approaches exhibits economy of scale. 


The same information for each unit in a homogeneous grouping 
provides summaries of critical cross-platform information. If we 
just had a failure on one spacecraft, we will look for that to happen 
on others. A merged database, allows for trending information to 
flow forward. As groups age, the individual members fail at 
different rates. From trending data on early failures, the remaining 
group can be monitored especially for known failures and 
degradation. 


Several approaches will not only lower the cost of swarms, but 
provide additional flexibility. As an example, the COSMOS open 
source control center product can handle multiple spacecraft 
simultaneously. It depends on the capabilities of the hosting 
hardware as to how many units can be supported. That, in turn, 
depends on the cpu and memory resources of the host. It is a scale- 
able approach. 


During a recent Cubesat Operations Course, the concept of Control 
Center as a Service evolved. This means the control center 
software is hosted “in the cloud” much like Amazon or Gmail. 
Here, you pay for MIPS and Gbytes. The solution scales as you 
need it. If one node starts to get overwhelmed, you can 
dynamically add nodes. There is no Apollo-era Control room. 
Everything is on the web (with proper consideration for security, 
particularly for commands), and you access your units from your 
phone or tablet, anywhere. Amazon and Google will argue that 
their requirements for availability and security exceed that of a 
space mission. 


We also explored the concept of a virtual operations controller. We 


modified standard control center software to text when a value was 
at its yellow or red limits. We can expand that to look at 
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combinations of telemetry points, and also have a rule-based 
program to examine the status. As the program evolves, and the 
software gets more capable (I hesitate to say, learns), the virtual 
ops controller can handle more of the routine monitoring and 
housekeeping tasks, and some of the upfront anomaly response. 
This becomes increasingly important as you move further away 
from Earth. We explored a Cubesat Swarm approach for 
exploration of the Asteroid belt, where the “control center” went 
along for the ride. This is almost necessary due to one-way light 
times, and loss of contact during solar occultation. 


We also consider the implementation of Cloud Services in the 
computer cluster of the Mothership. These cloud services are 
available to members of the swarm, and include data archiving, 
health assessment, communications, and updates. 


Avionics Suite 


The explorers baseline the GSFC PiSat software and hardware 
architecture for the flight computers. 


The Raspberry Pi-3 is a very capable processor. An earlier model 
was tested to operate to 150 kRad Total Ionizing Dose, with only 
the loss of several unused I/O interfaces. The major source of 
radiation at the destination will not be trapped particles, but rather 
ionizing cosmic rays of galactic origin. These are energetic, but 
sparse. The cluster computer will be enclosed in the nose of the 
mothership. 


A Raspberry Pi-3, requires 3.26 watts of power. It is quad core, 
operating at 1.4 GHz. It is a 64-bit machine, with 1 gigabyte of 
ram, and can achieve 2451 MIPS. It has a dedicated Graphics 
Processing Unit-based video pipeline that can handle 2D DSP. That 
is supported by the Open-GL software. 


Shared Databases 


Each member of the Exploring group will be self-documenting. It 
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will carry a copy of its Electronic Data Sheet (EDS) description, 
which can be updated. This defines the system architecture and 
capabilities, and has both fixed (as-built) and variable (what failed) 
entries. The main computer in the mothership has a copy of all of 
these, and can get updates by query. The Mothership also has 
parameters on each unit's state, such as electrical power remaining, 
temperature, etc. One value of the database is, if the mothership 
needs a unit with a high resolution imager, it knows what unit that 
is, and whether it has been deployed or not. If it has been deployed, 
it can query the unit on its position and health status. Implementing 
the EDS in a true database has advantages, since the position of the 
data item in the database also carries information. It also allows 
use of off-the-shelf database tools. The individual Cube-X's have a 
“light-weight” database, while the mothership has a more 
sophisticated one. The Motherships' own EDS is also stored in its 
database. All the schema's are the same. 


The Mothership is responsible for aggregating all of the Cubesat's 
housekeeping and science data, and transmitting it back to Earth. 
This is also facilitated by the structure imposed by the database. An 
Open Source version of an SQL database is preferred. Sqlite is 
preferred for the Cubesats. The EDS documents would be in XML. 


The Control Center's command and telemetry will also be stored in 
a database. If a compatible architecture is used across the flight and 
ground units, major operational efficiencies can be shown. The 
control center will also host and share the units' EDS's. You can 
think of incoming telemetry, or you can think of database updates. 


Compute cluster of convenience 


Within the explorer system, we can implement co-operative 
computing, with a goal of reducing downlink bandwidth to suite 
the capabilities of the system, while still returning information of 
value. This approach can be implemented with the Beowulf 
software, and networking resources onboard the mothership. 
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There will be no processing of the sensed data by the Cube-X, until 
it rejoins the transporter. The data will be relayed to the database 
on the larger unit. In some scenarios where the Cube-X cannot 
make it back, it may be possible to retrieve the data via a relay 


Use of a common hardware bus and software architecture for all 
swarm members, to the greatest extent possible, is a goal. Only the 
sensor sets will be unique. 


Surface Lander 


In a surface exploration scenario, a Cubesat-based architecture will 
serve as a local Mothership. It will be able to detach and deploy the 
explorers. An orbiting Cubesat can provide a “gods-eye” view, to 
target locations for direct exploration. It will also serve a a 
communications relay. The main problem will not be mobility, but 
rather avoiding floating off the surface. 


The ground-based unit will implement prox-ops in a more leisurely 
fashion, in that motion will be two-dimensional and at low speed. 
The surface rovers will not necessarily be retrieved. The local 
Mothership may be left at the observation site for additional data . 
The location of a lander/rover on the surface will be determined by 
the orbiting or station-keeping Mothership, with imaging. Standard 
space communications protocols will be used between the lander 
and the Mothership, via UHF link. 


ROS and other Open source software 
This section will discuss the software to be used on the Lava Tube 


explorers. It is, by choice, Open Source. 


Besides the Linux operating system, most of the needed 
application software is also available open source. We may run a 
real time version of embedded linux, or RTOS. ROS, Robot 
Operating System is an Open Source middleware framework for 
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robotics applications. It has been available since 2016. It has 
applications for mapping, navigation, perception, and simulation. 


CFE/CFS 


NASA GSFC, Flight Software Branch has developed and 


maintains a large application library of software “aps” for 
spacecraft onboard computer use. 


Beowulf Clustering 


The open source Beowulf clustering software, also developed by 
GSFC, allows individual computers to unite in a cluster 
architecture. 


Self-Check and Rad-Hard Software 


Built-in Fault Detection will be used on the surface rovers, both the 
transporter and the explorer models. A secondary computer will 
continuously scan the onboard systems for emerging problems and 
faults. In some cases, the fault can be remediating by power- 
cycling, or switching in a redundant unit. Physical problems, like 
jammed mechanisms might be fatal. Bigger picture, the fault 
detection system can monitor wheel rotation, and use the onboard 
inertial system to determine excessive tilt. 


On the surface, radiation is a problem. Rad Hard software is an 
approach that is software-based, and running on the system it is 
testing. From formal testing results, and with certain key 
engineering tools, we can come up with likely failure modes, and 
possible remediation's. Besides self-test, we can have cross- 
checking of systems. Not everything can be tested by the software, 
without some additional hardware. First we will discuss the 
engineering analysis that will help us define the possible hardware 
and software failure cases, and then we will discuss possible 
actions and remediation's. None of this is new, but the suggestion 
is to collect together best practices in the software testing area, 
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develop a library of RHS routines, and get operational experience. 
These routines will be open source. 


Another advantage of the software approach is that we can change 
it after launch, as more is learned, and conditions change. 


This section explores an approach to detect and respond to pending 
radiation damage to flight computers. 


The RHS has many diverse pieces, and is not just one software 
module, but can be dispersed. Some of the RHS modules run 
continuously and some are triggered on demand, due to a specific 
event. It is desirable to have as much fault/failure coverage as 
possible, while minimizing the impact on the host's memory and 
timing. 

The major problem for Spaceflight computers is radiation, 
although there are other environmental issues, and there can 
always be hardware and software residual errors that made it 
through testing. This becomes a much bigger problem during long 
cruise orbits to the outer planets, and for those planets with very 
large trapped particle fields. The RHS software approach will be 
flight software running on the Cube-X units, and on the main flight 
computer as well. This section explores an approach to detect and 
respond to pending radiation damage to flight computers. 


This approach is less expensive than flying radiation-hardened 
CPU's but does come with a risk. A Cubesat rad-hard compute 
architecture can be developed, but will be a more expensive 
approach. The software approach needs very thorough testing for 
validation. Even with Radiation hardened hardware, a “lighter” 
version of the rad-hard software would be a good approach. This 
provides Built-in self test. 


Rad Hard software is an approach that is software-based, and 
running on the system it is testing. From formal testing results, and 
with certain key engineering tools, we can come up with likely 
failure modes, and possible remediation s. Besides self-test, we can 
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have cross-checking of systems. Not everything can be tested by 
the software, without some additional hardware. First we will 
discuss the engineering analysis that will help us define the 
possible hardware and software failure cases, and then we will 
discuss possible actions and remediation's. None is this is new, but 
the suggestion is to collect together best practices in the software 
testing area, develop a library of RHS routines, and get operational 
experience. These routines will be open source. 


Another advantage of the software approach is that we can change 
it after launch, as more is learned, and conditions change. 


The RHS has many diverse pieces, and is not just one software 
module, but can be dispersed. Some of the RHS modules run 
continuously and some are triggered on demand, due to a specific 
event. It is desirable to have as much fault/failure coverage as 
possible, while minimizing the impact on the host's memory and 
timing. 


You're way ahead when you have some idea what is likely to fail, 
derived from testing, industry reports, and case studies. Fault 
coverage has to be as complete as possible, but we should ensure 
we have the known failure modes covered. Of course, some 
failures were missed in testing, resulting in their presence 
becoming known even in the operational environment. 


It is also critically important to know exactly what software has 
been loaded into the flight computer. What if you have multiple 
copies, and don't know which one is in use? Configuration Control 
prevents that, right? It has happened. 


There is also now a general policy of “test what you fly, fly what 
you test.” You might have included diagnostic code for integration 
testing, and pull it out before flight. Wrong. Now the code you are 
going to fly is untested. The tested version include the 
instrumentation code. Even though it will never be used, it takes up 
some space, so cache footprints, memory boundary's, and pipeline 
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contents are different. 


We also need to carefully consider the failure recovery. Sometimes, 
we will need the system to reboot itself. That's disruptive, but 
necessary in some cases. We want to take every possible path 
before going down that one. 


The flight computers are operating in a hostile environment. There 
are known failure modes in this environment, that have to be 
covered. Failures will be transient or hard. Sometimes, hard 
failures result in a state that is not recoverable. Transient failures, 
on the other hand, are the hardest to find. We can observe the 
results, and try to work backward to the root cause. That is where 
good up-front analysis and data from system test is invaluable. 
Some architectures, such as the ARM Cortex-R7 have built-in 
hardware failure detection. That's a good approach, but it leaves 
many potential failures uncovered. 


We can tap industry best practices code for system testing. We can 
also use testing code developed for system POST (power-on-self- 
test) as an example. POST is accomplished after a reset, but before 
the system begins to run operational code. It does allowed for 
checking internal functionality. POST should certainly be included 
in our repertoire. POST doesn't have specific run time 
requirements (except the annoyance threshold). A large block of 
memory can be tested in sections, to avoid adversely affecting 
system timing. 


You're way ahead when you have some idea what is likely to fail, 
derived from testing, industry reports, and case studies. Fault 
coverage has to be as complete as possible, but we should ensure 
we have the known failure modes covered. Of course, some 
failures were missed in testing, resulting in their presence 
becoming known even in the operational environment. 
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Underground exploration sensor suite 


Such parameters as atmospheric pressure (if any), temperature, 
light level, radiation detection, and such provide guidelines for a 
rover sensor suite. In addition, an odometer function provides 
distances traveled. For further details, we might deploy a ground 
penetrating radar on a rotation mount, so it could measure distance 
to the surface as well. GPR works well in dry materials and can 
detect changes in density up to 30 meters. Testing for gases would 
be a good idea, as would having the ability to sample the wall and 
floor material. A lidar unit could provide a 3-D map of the tube, 
but this puts additional strain on onboard power, computation, and 
data storage resources. 


A stereo camera with changeable focus, along with the a video 
processing pipeline in the computer, would be very useful. 


Ops concept. 


Once on the surface, the transporter can be imaged by orbital 
assets, and its position determined. This is the starting point for 
navigation. After that, keeping track of distance and turns, the 
location on the surface is known. Further sightings from orbit will 
update these data. 


With the caves or tubes located by in-orbit assets, the transporter 
vehicle will take the explorer vehicles to the entrance. The 
transporter will stay at the mouth of the cave, and deploy an 
explorer. The transporter will run functional tests on the explorer 
before deployment, and ensure that it is fully functional. The 
transporter will also deploy a beacon at the cave mouth, to allow 
the explorer to find its way back. The transporter vehicle will not 
enter the caves. 


For navigation on the Lunar and Martian surface there is currently 
no GPS equivalent. Maps exist of the surface, based on orbital 
imaging. Dead reckoning could be used, and the two Martian 
moons are in stable orbits, so an ephemeris could be calculated. 
Then, by observation of their rising and falling, a position on the 


57 


surface could be determined, not to a great accuracy. But, 
Columbus made it to America using a compass and an astrolabe 
for star positions. 


The ends of lava caves will be sought, to allow a horizontal entry. 
On the moon, due to the large angle of repose due to lower lunar 
gravity, the slope to enter the cave may be excessive. The 
property's of lunar regolith are fairly well understood, due to 
samples returned by the Apollo missions. These are housed at 
Johnson Space Center, Houston. 


Another approach to entering the tube would be through the 
“skylight” at the top. These features are due to a partial collapse in 
the tube. The rover could be winched down into the tube by the 
transporter. Recovery of the unit will be problematic. Theses 
scenarios are being worked out and validated by field trials. 
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TRL 


The Technology Readiness Level (TRL) is a measure of a device's 
maturity for use. There are different TRL definitions by different 
agencies (NASA, DoD, ESA, FAA, DOE, etc). TRL are based on a 
scale from 1 to 9 with 9 being the most mature technology. The use 
of TRLs enables consistent, uniform, discussions of technical 
maturity across different types of technology. We will discuss the 
NASA one here, which was the original definition from the 1980's. 


1. Basic principles observed and reported. This is the lowest 
"level" of technology maturation. At this level, scientific research 
begins to be translated into applied research and development. 


2. Technology concept and/or application formulated. 


Once basic physical principles are observed, then at the next level 
of maturation, practical applications of those characteristics can be 
‘invented’ or identified. At this level, the application is still 
speculative: there is not experimental proof or detailed analysis to 
support the conjecture. 


3. Analytical and experimental critical function and/or 
characteristic proof of concept. 


At this step in the maturation process, active research and 
development (R&D) is initiated. This must include both analytical 
studies to set the technology into an appropriate context and 
laboratory-based studies to physically validate that the analytical 
predictions are correct. These studies and experiments should 
constitute "proof-of-concept" validation of the 
applications/concepts formulated at TRL 2. 


4. Component and/or breadboard validation in laboratory 
environment. 
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Following successful "proof-of-concept" work, basic technological 
elements must be integrated to establish that the "pieces" will work 
together to achieve concept-enabling levels of performance for a 
component and/or breadboard. This validation must be devised to 
support the concept that was formulated earlier, and should also be 
consistent with the requirements of potential system applications. 
The validation is "low-fidelity" compared to the eventual system: it 
could be composed of ad hoc discrete components in a laboratory 


5. Component and/or breadboard validation in relevant 
environment. 


At this level, the fidelity of the component and/or breadboard 
being tested has to increase significantly. The basic technological 
elements must be integrated with reasonably realistic supporting 
elements so that the total applications (component-level, sub- 
system level, or system-level) can be tested in a 'simulated' or 
somewhat realistic environment. 


6. System/subsystem model or prototype demonstration in a 
relevant environment (ground or space). 


A major step in the level of fidelity of the technology 
demonstration follows the completion of TRL 5. At TRL 6, a 
representative model or prototype system or system - which would 
go well beyond ad hoc, 'patch-cord' or discrete component level 
breadboarding - would be tested in a relevant environment. At this 
level, if the only ‘relevant environment’ is the environment of 
space, then the model/prototype must be demonstrated in space. 


7. System prototype demonstration in a space environment. 
TRL 7 is a significant step beyond TRL 6, requiring an actual 
system prototype demonstration in a space environment. The 


prototype should be near or at the scale of the planned operational 
system and the demonstration must take place in space. 
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The TRL assessment allows us to consider the readiness and risk of 
our technology elements, and of the system. 


TRL's can be applied to hardware or software, components, boxes, 
subsystems, or systems. Ultimately, we want the TRL level for the 
entire systems to be consistent with our flight requirements. Some 
components may have higher levels than needed. 


The TRL assessment allows us to consider the readiness and risk of 
our technology elements, and of the system. 


TRL assessment of Cube-X 


This section discusses our estimates of the Technology Readiness 
Levels of the various mission components. 


Mother ship to Xubesat communication — TRL-3. 

Cubesat — Earth, Lunar, and Mars Missions, TRL-9 (although, not 
on the surface). MarCO- A and -B went with the Insight mission to 
Mars. Lunar Flashlight and 12 other Cubesat missions will go to 
the Moon on the planned 2021 Artemis Mission. 

Core Flight System/Core Flight Executive software — TRL-9. 


Raspberry Pi flight computer — TRL-9 for Earth missions, TRL-7 
for Lunar or Mars. 


Computer cluster with Beowulf — TRL-9. (Singapore's X-sat.) 
PNN algorithm - TRL-6. 
Rad-hard software — TRL-3. 


Onboard EDS relational database — TRL-7. 
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Onboard testing of Cubesats before deployment — TRL-4. 


Cubesat Cluster (Cubesat Constellation, 50 units in Earth Orbit, 
2015; Indian launch of 104 Cubesats, February 2017) — TRL-9. 


Swarm Robotics — TRL 4. 
Underground Navigation — TRL-4. 
Mobility Platform — not chosen yet. 


Where to see. 


Lava tubes can be seen at various locations on Earth. There are 
some in Iceland, Raufarhdlshellir, and Surtshellir, the Leviathan 
Cave in Kenya, Gruta das Torres in Portugal, Manjang Cave in 
Korea, Cueva de los Verdes in Spain, Lanzarote in the Canary 
Islands, Kazumura Cave on the island of Hawaii, and in the State 
of Oregon there is Lava River Cave. There is also Lava Beds 
National Monument, in Bend, Oregon, extending into California. 
There are over 750 Lava tubes. 


Afterword 


Lava tubes can solve a problem for human habitation and work on 
the Moon, Mars, and other places in our Solar System. The initial 
discovery's were made by imaging from orbit. We have Lava tubes 
on Earth, and Rovers, similar to current Mars Rovers have gone in 
these to check their performance in the underground environment. 


The point of the Cube-X described in this book is that a swarm of 
small modular units will be a less expensive approach, and will 
provide more flexibility, capability for simultaneous observations 
from different points of view, and the ability to cover more ground 
(or, underground) in one launch. Due to standardization and 
modularity, the costs will be lesser, as well. There's a whole lot of 
places to explore out there, and we can't do them one at a time 
anymore. 
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Glossary of terms and acronyms 


Actuator — device which converts a control signal to a mechanical 
action. 

A/D, ADC — analog to digital converter. 

Agent — software that acts as a user. 

AI — artificial intelligence. 

ALHAT — NASA's Auto Landing Hazard Avoidance Technique. 

ALI — autonomous lunar investigator. 

AML - Agent modelling language 

Analog — concerned with continuous values. 

Angle of repose — steepest angle of descent of a granular material. 

Aquafer — underground layer of water bearing permeable rock. 

AR&D — Autonomous Rendezvous and Docking. 

ART — Autonomous Reconfigurable Technology. 

ASIN — Amazon Standard Inventory Number. 

Astro-Geology — study of the geology of planets, etc, other than 
Earth. 

Astro-speleology — study of caves on other planets. 

Async — asynchronous; 2 processes not sharing the same clock. 

Autonomic computing — self-managing of distributed resources. 

Axel — JPL Rover. 

BAA — Broad Agency Announcement (U. S. Government) 

BEES - Biologically Inspired Engineering for Exploration 
Systems. 

Biosignature — indication of life 

BIST — built-in self test. 

BRAILLE — (NASA) Biologic and Resource Analog Investigations 
in Low Light Environments. A cave explorer robot. 

Bus — data channel, communication pathway for data transfer. 

CAN - controller area network. 

Chip — integrated circuit component. 

Clock — periodic timing signal to control and synchronize 
operations. 

COSMOS (Ball Brothers) Open Source Control Center Software. 

CPU — central processing unit. 
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CRADA — Cooperative Research and Development Agreement (U. 

S. Government and industry) 

CSA — Canadian Space Agency. 

Cubesat — a small, well-defined satellite. Scaleable. 

Cube-x — an explorer robot, based on the Cubesat architecture and 
approach. 

Device driver — specific software to interface a peripheral to the 
operating system. 

Dissolution caves — caves formed by a liquid dissolving material. 

DOF — degree of freedom. 

DOI — digital object identifier. 

Droid — robot. 

DTM - digital terrain model. 

EDS — Electronic Data Sheet.. 

ELF — extremely low frequency 

EMF - electro-magnetic field or force. 

ENI — evolve-able neural interface. 

ENS — evolve-able neural system. 

Erosional caves — formed by flowing streams. 

ESA — European Space Agency. 

EVS — evolve-able neural systems 

FAST — Formal Approach to Swarm Technology. 

Flatsat — engineering model of a Cubesat's electronics, laid out on 
a table for easy access during testing. 

FPGA — field programmable gate array. 

Fracture cave — formed when soluable layers dissolve, leaving 
rock. 

GEO — geosynchronous Earth orbit. 

Giga - 10? or 2”. 

GHz — giga (10°) hertz. 

GNFIR - GSFC Natural Feature Image Recognition System. 

GPR — ground penetrating radar. 

GPS — global positioning system 

Gray - unit of radiation, =100 rad 

GSFC — Goddard Space Flight Center, Greenbelt, Maryland. 
NASA Center for unmanned spacecraft near Earth. 

Helictite — speleothem that changed its axis multiple times during 
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development. 

HLNS — higher level neural system 

Hz — Hertz, or cycles per second. 

IEEE - Institute of Electrical and Electronic Engineers. 
Professional organization and standards body. 

Intelsat = International Telecommunications Satellite Organization. 

Interrupt — an asynchronous event to signal a need for attention 
example: the phone rings). 

IP — Intellectual Property. 

IR — infrared, 1-400 terahertz. Perceived as heat. 

IRAD - (U. S. Gov't) Independent Research & Development. 

ISBN — International Standard Book Number. 

ISRS — In-space robotic servicing. 

ISS — International Space Station. 

JPL — (NASA) Jet Propulsion Lab. 

Karst — formation caused by dissolution of rock. 

LARA — Lunar exploration and exploitation. 

Lava Cave — a cave in volcanic rock 

Lavacicles — stalactite, grows down from the ceiling. 

Lava fan — a fan shaped structure of congealed lava, someimes at 
the openning of a lava tube. 

LIDAR - Light Detection and ranging. Radar, at a higher 
frequency. 

LLNS — lower level neural system. 

LOP-G — lunar orbiting platform — gateway. 

LORAN — World War -II era radio navigation system 

LRO — (NASA) Lunar Reconnaissance Orbiter. 

LV — launch vehicle. 

MCLSS - Mars Cave Life Support System. 

Mineralogy — study of the physical propertys of minerals. 

Minerogenesis — the formation of minerals. 

Mothership — large vehicle/platform performing services such as 
transportation or recharging to individual explorers. Can 
also provide cloud services. 

NASREM - NASA/NBS Standard Reference Model for Telerobot 
Control System 

NASA — National Aeronautics and Space Administration (USA) 
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NBF - Neural basis function. 

NBS - National Bureau of Standards, now NIST. 

NIST — National Institutes of Standards and Technology. 

NOAA — National Oceanographic and Atmospheric 

Administration. (USA) 

NOSA - NASA Open Source Agreement. 

Open source — methodology for hardware or software development 
with free distribution and access. 

ORU — Orbital Replacment Unit. 

OSAL — Operting System Abstraction Layer 

Pahoehoe flows — surface moving lava. 

PAM -Prospecting Asteroid Mission. 

RCS — robot control system. 

RFI — Request for Information. 

Rilles — troughs, possibly collapsed lava tubes. 

ROS — Robot Operating System (software) 

RRM — Robotic Refueling Mission. 

RSV — RESTORE Servicing Vehicle. 

RTOP - Research and Technology Objectives and Plans/ 

RTOS - real-time operating system. 

RWS — Robotic Work Station, on Space Station. 

SARAH - Self Adaptive Robotic Auxiliary Hand, (on Dextre). 

SCADA - Supervisory Control and Data Acquisition — for 
industrial control systems. 

SELENE — (Japan) Speleological and Engineering Explorer. Also 
used by Novelist H. G. Wells as the name of the moon 
dwellers. 

Sensor — a device that converts a physical observable quantity or 
event to a signal. 

Serial — bit by bit. 

Shotcrete — sprayed concrete. 

SLAM — Simultaneous Location and Mapping - 

Stratigraphy — study of rock layers, sedimentary and volcanic. 

Skylight — partially collapsed ceiling in lava tube, providing an 
entry point. 

SM - servicing mission. 

Solutional Cave — formed in soluble limestone. 
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Speleothem — material formed in a limestone cave by deposition of 
minerals. 

Speleologists — Professional Cave explorer and scientist. 

Speleonauts — cave explorers in space. 

Spelunker — amateur cave explorer. 

SSN — (DARPA) sub-surface navigation. 

Stalactite — grows down from the ceiling, and holds tight. 

Stalagmite — Might grow up due to dripping from stalactites. 

System — a collection of interacting elements and relationships 
with a specific behavior. 

System of Systems — a complex collection of systems with pooled 
resources. 

TDRSS - Tracking and Data Relay Satellite. 

Telerobot — a robotic system with a human in the loop. 

Transceiver — receiver and transmitter in one box. 

TRL — technology readiness level. 

USGS — United States Geological Society 

Watchdog — hardware/software function to sanity check the 
hardware, software, and process; applies corrective action if 
a fault is detected; fail-safe mechanism. 

XML - extensible markup language. Human and machine readible 
format. 


67 


References 


Asmar, Sami; Matousek, Steve “Mars Cube One (MarCO), First 
Planetary CubeSat Mission,” (presentation), 2014, JPL, avail: 
www.jpl.nasa.gov/cubesat/missions/marco.php 


Avery, Keith; Fenchel, Jeffery; Mee, Jesse; Kemp, William; Netzer. 
Richard; Elkins, Donald; Zufelt, Brian; Alexander, David; “Total 
Dose Test Results for Cubesat Electronics, ” 2011 IEEE Radiation 
Effects Data Workshop, 25-29 July 2011, Las Vegas, NV, pp. 1-8, 
978-1-4577-1281-4. 
avail:www.cosmiacpubs.org/pubs/TDTRCE. pdf 


Boston, P.; Frederick, G.; Welch, S.; Werker, J.; Meyer, T.R.; 
Sprungman, B.; Hildreth-Werker, V.; Murphy, D.; Thompson, S.L. 
“System Feasibility Demonstrations of Caves and Subsurface 
Constructed for Mars Habitation and Scientific Exploration" 
USRA Reports,” 2004, NASA Institute for Advanced Concepts. 
Avail: 

http://www.niac.usra.edu/files/studies/final_report/710Boston.pdf 


Boissier, Olivier, et al Multi-Agent Oriented Programming: 
Programming Multi-Agent Systems Using JaCaMo (Intelligent 
Robotics and Autonomous Agents series), 2020, MIT Press, 
ISBN-0262044579 


Boston, et al, “Human utilization of subsurface extraterrestrial 
environments,” 2003, Gravitational and Space Biological Bull., 
Jun;16(2):121-31, 
https://www.researchgate.net/publication/254705471 


Braunl, Thomas; Embedded Robotics: Mobile Robot Design and 
Applications with Embedded Systems Springer; 2nd ed. edition 
(July 28, 2006) ISBN-3540343180. 


Bunnell, Dave; Rea, Thomas G. (ed), Caves of Fire: Inside 


68 


America's Lava Tubes, National Speleological Society, 2008, 
ISBN-101879961318. 


Cervenk, Radovan, Trencansky, Ivan The Agent Modeling 
Language - AML: A Comprehensive Approach to Modeling Multi- 
Agent Systems (Whitestein Series in Software Agent Technologies 
and Autonomic Computing), 2007, ISBN — 978-3764383954. 


Challa, Obulapathi N., McNair, Janise “Distributed Data Storage 
on Cubesat Clusters,” Advances in Computing 2013, (3) 3 pp.36- 
49. avail: http://article.sapub.org/10.5923.j.ac.20130303.02.html 


Clancey, William J. Working on Mars: Voyages of Scientific 
Discovery with the Mars Exploration Rovers (MIT Press), 2012, 
ISBN-026201775X. 


Cushing, G. E. “Candidate Cave entrances on Mars,” J. Cave & 
Karst Studys, 2012, pp 33-47. 


Cudmore, Alan NASA/GSFC's Flight Software Architecture: Core 
Flight Executive and Core Flight System, NASA/GSFC Code 582. 


Cudmore, Alan Pi-Sat: A Low Cost Small Satellite and Distributed 
Mission Test Program, NASA/GSFC Code 582, avail: 
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20150023353. 
pdf 


Curtis, S. A. et al “Use of Swarm Intelligence in Spacecraft 
Constellations for the Resource Exploration of the Asteroid Belt,” 
2003, Third International Workshop on Satellite Constellations and 
Formation flying, Pisa, Italy. 


Daga, Andrew (et al), “Lunar and Martian Lava Tube Exploration 
as Part of an Overall Scientific Survey,” White Paper submitted to 
the Planetary Sciences Decadal Survey, 2013-2022. 

Davis, Clay GPS-like Navigation Underground, 2010, IEEE/ION 


69 


Position, Location and Navigation Symposium, 2019, IEEE 
Xplore, DOI-10.1109/PLANS.2010.5507196. 


Dubowsky, S. et al “A Concept Mission: Microbots for Large-Scale 
Planetary Surface and Subsurface Exploration,” AIP Conference 
Proceedings 746, 1449 (2005); https://doi.org/10.1063/1.1867276. 


Dudek, Gregory Jenkin, Computational Principles of Mobile 
Robotics, 2000, Cambridge University Press, ISBN 0521568765. 


Engineering and Medicine, National Academies of Sciences 
(Author), Division on Engineering and Physical Sciences (Author), 
Space Studies Board (Author), Achieving Science with Cubesats: 
Thinking Inside the Box, National Academies Press, 2016, ISBN- 
978-0309442633. 


Fortescue, Peter and Stark, John Spacecraft System Engineering, 
2nd ed, Wiley, 1995, ISBN 0-471-95220-6. 


Goldberg, S., Maimone, M., L. Matthies, L. ;"Stereo Vision and 
Rover Navigation Software for Planetary Navigation, IEEE 
Aerospace Conference, March 2002, pp. 2025-2036, Big Sky, 
Montana. 


Handwerk, Brian “First Moon 'Skylight' Found -- Could House 
Lunar Base?”, National Geographic, October, 2009. 


Harmsworth, Tony Going to Mars: An Essay, 2019, ASIN- 
BO7T3QP33N. 


Hayati, Samad, Lavery, Dave “Mars Technology Program,” 2005, 
iSAIRAS 2005. 


Hall, John “maddog”; Gropp, William Beowulf Cluster Computing 
with Linux, 2003, ISBN -0262692929. 


Kramer, Jon California Underground: A Guide to Caves, Mines 


70 


and Lava Tubes, 2018, ISBN-978- 1591938712. 


Landis, G. "Teleoperation from Mars Orbit: A Proposal for Human 
Exploration," Acta Astronautica, Vol. 61, No. 1, 59-65 (Jan. 2008); 
also paper IAC-04-IAA.3.7.2.05, 55th International Astronautical 
Federation Congress (2004). 


Larson, Charlie; Larson, Jo Lava Bed Caves, 1990, ABC 
Publishing, ISBN-1886168040. 


Leone, Giovanni, "A Network of Lava Tubes as the Origin of 
Labyrinthus Noctis and Valles Marineris on Mars,".Journal of 
Volcanology and Geothermal Research, Vol 277, May, 2014. 


“Lunar Lava Tubes Radiation Safety Analysis". Division for 
Planetary Sciences 2001 meeting. American Astronomical Society. 
November 2001. 


Madni, Mohamed Atef; Raad, Raad; Tubbal, Faisal “Inter-Cubesat 
Communications: Routing Between Cubesat Swarms in a DTN 
Architecture,” presentation, avail: 
https://iCubesat.org/papers/2015-2/2015-b-2-1. 


McLoughlin, Ian; Bretschneider, Timo; Ramesh, Bharath “First 
Beowulf Cluster in Space,” Linux Journal, September 2005, Issue 
#137, article 8097. 


Mueller, Robert P. “Space Environment & Planetary Civil 
Engineering Basics,” NASA KSC. Avail: 
https://kiss.caltech.edu/workshops/3d/presentations/mueller.pdf 


NASA, Systems Engineering Handbook, Rev. 2, June 2017, avail: 
https://www.nasa.gov/connect/ebooks/nasa-systems-engineering- 


handbook 


NASA, Observations of actively forming lava tubes and 
associated structures, Hawaii, 2019, TM X-62014, 1971, ASIN- 


71 


BO7XVSKRP9. 


Nwana, H.S "Software Agents: An Overview,” (1996). Knowledge 
Engineering Review, 21 (3). 


Purcell, David Guide to the lava tube caves of Central Oregon, 
1977, ASIN-BOOO7AYRA2. 


Richardson, J.W. et al. “The Relationship Between Lava Fans and 
Tubes on Olympus Mons in the Tharsis Region, Mars,” 2009, 40th 
Lunar and Planetary Science Conference, Abstract #1527 


Schenker, P. S. "NASA Research and Development for Space 
Telerobotics," IEEE Transitions on Aerospace and Electronic 
Systems, Sept 1988, v 24 n 5 pp 523-534. 


Schroer, Bernard J. "Telerobotics Issues in Space Application”, 
Robotics and Autonomous Systems, V. 4 Issue 3, Nov 1988, pp 
233-344. 


Sebens, C. An agent-based tetrahedral walker, 2005, avail: 
Research Gate, DOI: 10.1109/AERO.2006.1656035. 


Shick, Harry Understanding Lava Tubes And Lava Caves, 2009, 
ISBN-1425189857. 


Spangelo, et al “JPL's Advanced CubeSat Concepts for 
Interplanetary Science and Exploration Missions, Cubesat 
Workshop,” 2015, California Institute of Technology, JPL. 
https://digitalcommons.usu.edu/cgi/viewcontent.cgi? 

article=33 13 &context=smallsat 


Stakem, Patrick H. "The Brilliant Bulldozer: Parallel Processing 
Techniques for Onboard Computation in Unmanned Vehicles", 
15th AUVS Symposium, San Diego, Ca. June 6-8, 1988. 

Stakem, Patrick H. "Linux in Space", Oct. 2, 2003, invited 


72 


presentation, Institution of Electrical Engineers, Sheffield Hallam 
University, Sheffield, UK. 


Stakem, Patrick H. “Free Software in Space-the NASA Case,” 
invited paper, Software Livre 2002, May 3, 2002, Porto Allegre, 
Brazil. 


Stakem, Patrick H., “ARM-based Compute Cluster for in-situ 
sensed data processing,” 2019, Presented at the NASA Goddard 
Space Flight Center Planetary CubeSats Symposium. 


Stakem, Patrick H., Korol, Guilherme, Gomes, Gabriel Augusto, 
“A Lightweight Open Source Command and Control Center and its 
Interface to Cubesat Flight Software.” Presented at Flight 
Software-15 Conference (FSW-15), The Johns Hopkins University, 
Applied Physics Laboratory. 


Stakem, Patrick H.; Rezende, Aryadne; Ravazzi, Andre “Cubesat 
Swarm Communications,” 2016. 


Stakem, Patrick H.; Da Costa, Rodrigo Santos Valente; Rezende, 
Aryasdne; Ravazzi, Andre “A Cubesat-based alternative for the 
Juno Mission to Jupiter,’ 2017, Proceedings of the NASA/GSFC 
Flight Software Conference. 


Stakem, Patrick H., Kerber, Jonathas “Rad-hard software, Cubesat 
Flight Computer Self-monitoring, Testing, Diagnosis, and 
Remediation,” 2017, available from the author, 
pstakem1@jhu.edu. 


Stakem, Patrick H. “Lunar and Planetary Cubesat Missions,” 
March Volume 15, Polytech Revista de Tecnologia e Ciéncia, 
avail: http://www.polyteck.com.br/revista_online/ed_15.pdf. 


Stakem, Patrick H., Martinez, Jose Carlos; Chandrasenan, Dr. 


Vishnu; Mitra, Yash, “A Cubesat Swarm Approach for Exploration 
of the Asteroid Belt,” July 2018, presented at the NASA Goddard 


73 


Space Flight Center Planetary CubeSats Symposium. 


Tan, Ying GPU-based Parallel Implementation of Swarm 
Intelligence Algorithms, 2016, Ist ed, Morgan Kaufmann, ISBN- 
978-0128093627. 


Truszkowski, Walt; Hallock, Harold L.; Rouff, Christopher; Karlin, 
Jay; Rash, Hinchey, Mike; Sterritt, Roy Autonomous and 
Automatic Systems,: With Applications to NASA Intelligent 
Spacecraft Operations and Exploration Systems, Monographs in 
System and Software Engineering, Springer, 009, ISBN 
9781846282331. 

Truszkowski, Walt; Clark, P. E.; Curtis, S.; Rilee, M. Marr, G. 
ANTS: Exploring the Solar System with an Autonomous 
Nanotechnology Swarm. J. Lunar and Planetary Science XXXIII 
(2002). 


Truszkowski, Walt; Clark, P. E.;, Curtis, S.; Rilee, M. Marr, G. 
ANTS: Exploring the Solar System with an Autonomous 
Nanotechnology Swarm. J. Lunar and Planetary Science XXXIII 
(2002). 


Truszkowski, Walt; Prototype Fault Isolation Expert System, 1984, 
RTOP 506-54-66. GSFC. 


von Ehrenfried, Manfred From Cave Man to Cave Martian: Living 
in Caves on the Earth, Moon and Mars, 2019, Springer praxis, 
ISBN-3030054071. 


Waters, Aaron C., Selected Caves & Lava Tube Systems in & Near 
Lava Beds National Monument California, USGS Bulletin 1673 


Wells, H. G. The First Men in the Moon, 1901, repub. 2000, Dover, 
ISBN-978-0486414188. 


Whittaker, William, Astrobotic Technology, “Technologies 


74 


Enabling Exploration of Skylights, Lava Tubes, and Caves,” 2012, 
NASA Innovative Advanced Concepts (NIAC) Phase I. 


Wilcox, Brian H.; “Robotic Vehicles for Planetary Navigation,” 
Journal of Applied Intelligence, 2nd Qtr 1992, Kluwer Academic 
Publishers, Boston MA., 1992, pp. 181-193. 


Wooldridge, Michael J. (2002). An Introduction to Multiagent 
Systems. New York: John Wiley & Sons. p. 27. ISBN 978-0-471- 
49691-5. 


Wooster, Paul; Boswell, David; Stakem, Patrick; Cowan-Sharp, 
Jessy “Open Source Software for Small Satellites,” SSC07-XII-3, 


Wynne, J. Judson, “The Scientific Importance of Caves in our 
Solar System,” National Speleological Society News, March, 
2016. 


Young, Filson Christopher Columbus and the New World of His 
Discovery; a Narrative, With a Note On the Navigation, 2018, 
ISBN-978-1377916637. 


ANTS References, courtesy attic.gsfc.nasa.gov/ants: 


IEEE Aerospace and Electronic Systems Magazine, June 2007, 
Vol. 22, Issue 6, pp. 22-30: “Tetrahedral Robotics for Space 
Exploration” 


Abrahantes, M.A. et al. 2006 “Gait Design and Modeling of a 12- 
Tetrahedron Walker Robot” 


Rilee, M.L. et al. 2005 “Working notes on a developmental 
approach to autonomous spacecraft and the recovery of the Hubble 
Space Telescope,” AAAI Spring Symposium on Developmental 
Robotics, March 21-23, 2005, Stanford, CA 


75 


Cheung et al, 2005 Real-Time 3-D Virtual Graphical Interface for 
Telerobotic Control, Presentation 


Curtis et al, 2005 Reconfigurable Tetrahedral Walker, Presentation 


Mining Amorphous Transporter Explorer (MATE) Far North 
Mining Operations,Clark, White Paper, 2005 


MSW Document, Clark et al, STAIF 2005, Power for ANTS 
Systems, 


Near Term Reconfigurable Concepts And Components For Lunar 
Exploration and Exploitation, Clark et al, IAC 2004, LARA. 


Biologically Inspired Engineering And Exploration Mission 
Concept, Components And Requirements For Asteroid Population 
Survey Clark et al, IAC 2004, PAM, Paper . 

Clark et al, ISTC 2004, Biological Analogues, Paper . 


ANTS For The Human Exploration And Development Of 
Space,Curtis et al, 2003. 


Use Of Swarm Intelligence In Spacecraft Constellations For The 
Resource Exploration Of The Asteroid Belt,Curtis et al, 2003. 


Use Of Swarm Intelligence In Spacecraft Constellations For The 
Resource Exploration Of The Asteroid Belt,Curtis et al, 2003 . 


Onboard Science Software Enabling Future Space Science And 
Space Weather Missions,Rilee et al, 2002. 


Onboard Science Software Enabling Future Space Science And 
Space Weather Missions,Rilee et al, 2002. 


Exploring The Solar System With An Autonomous 
Nanotechnology Swarm, Clark et al, 2002. 


76 


Using ANTS To Explore Small Body Populations In The Solar 
System,Clark et al, 2001. 


An Artificial Intelligence Approach To Asteroid Belt Resource 
Exploration, Curtis et al, 2000. 


An Artificial Intelligence Approach To Asteroid Belt Resource 
Exploration,Curtis et al, 2000. 


77 


Resources 


Expanded Guidance for NASA Systems Engineering, Volume 1, 
System Engineering Practices, NASA, Mach 2016. 


NASA Systems Engineering Handbook, NASA/SP-2007-6105, 
Rev. 1. (available on Google Books, Amazon, and others). 


A Survey of Multi-Robot Cooperation in Space, 
avail:https://pdfs.semanticscholar.org/al 93/b162d914f673ea61409 
Oc68fac87c76b8d1 .pdf 


Planetary Science Vision Workshop. - 
https://www.Ipi.usra.edu/V2050/ 


Small Spacecraft Technology State of the Art, NASA-Ames, 
NASA/TP2014-216648/REV1, July 2014. 


Core Flight System (CFS) Deployment Guide, Ver. 2.8, 9/30/2010, 
NASA/GSFC 582-2008-012. 


http://sen.com/news/cubesats-set-for-new-role-as-planetary- 
explorers 


info@cuberover.com 
Caves of Mars - 
https://web.archive.org/web/20070625 1903 17/http://www.highmar 


s.org/niac/ 


International Planetary Cave Research Workshop 
http://www.lpi.usra.edu/meetings/caves2011/caves20112nd.shtml 


https://www.nasa.gov/audience/foreducators/robotics/imagegallery 
/r_TETwalker.jpg.html 


Technologies Enabling Exploration of Skylights, Lava Tubes, and 


78 


Caves, NASA Innovative Advanced Concepts, Phase I, 2022/2012, 
Final Report, Astrobotic Technology. 


Kerber, Laura, “Moon Diver Mission Concept - Descending into a 
Moon Cave to Better Understand the Solar System's Largest 
Volcanic Eruptions" kiss.caltech.edu. 


http://www.mind.ilstu.edu/curriculum/ants_nasa/ants_pam.php 
http://wiki.developspace.net/Open_ Source Engineering Tools 


https://software.nasa.gov/software/MSC-26323-1 — NASA CFS 
training 


Wikipedia, various. 


Lava Tubes in the U.S. 
Lave tubes may be visited at the following National Parks. 
e Craters of the Moon National Monument, Idaho 
e El Malpais National Monument, New Mexico 
e Hawaii Violcanos National park 
e Lava Beds National Monument, California 
e Mojave National Preserve, California 


e Sunset Crater National Monument, Arizona 


79 


If you enjoyed this book, you might also be 
interested in some of these. 


Stakem, Patrick H. 16-bit Microprocessors, History and 
Architecture, 2013 PRRB Publishing, ISBN-1520210922. 


Stakem, Patrick H. 4- and 8-bit Microprocessors, Architecture and 
History, 2013, PRRB Publishing, ISBN-152021572X, 


Stakem, Patrick H. Apollo's Computers, 2014, PRRB Publishing, 
ISBN-1520215800. 


Stakem, Patrick H. The Architecture and Applications of the ARM 
Microprocessors, 2013, PRRB Publishing, ISBN-1520215843. 


Stakem, Patrick H. Earth Rovers: for Exploration and 
Environmental Monitoring, 2014, PRRB Publishing, ISBN- 
152021586X. 


Stakem, Patrick H. Embedded Computer Systems, Volume l, 
Introduction and Architecture, 2013, PRRB Publishing, ISBN- 
1520215959. 


Stakem, Patrick H. The History of Spacecraft Computers from the 
V-2 to the Space Station, 2013, PRRB Publishing, ISBN- 
1520216181. 


Stakem, Patrick H. Floating Point Computation, 2013, PRRB 
Publishing, ISBN-152021619X. 


Stakem, Patrick H. Architecture of Massively Parallel 
Microprocessor Systems, 2011, PRRB Publishing, ISBN- 
1520250061. 


Stakem, Patrick H. Multicore Computer Architecture, 2014, PRRB 


80 


Publishing, ISBN-1520241372. 


Stakem, Patrick H. Personal Robots, 2014, PRRB Publishing, 
ISBN-1520216254. 


Stakem, Patrick H. RISC Microprocessors, History and Overview, 
2013, PRRB Publishing, ISBN-1520216289. 


Stakem, Patrick H. Robots and Telerobots in Space Applications, 
2011, PRRB Publishing, ISBN-1520210361. 


Stakem, Patrick H. The Saturn Rocket and the Pegasus Missions, 
1965, 2013, PRRB Publishing, ISBN-1520209916. 


Stakem, Patrick H. Visiting the NASA Centers, and Locations of 
Historic Rockets & Spacecraft, 2017, PRRB Publishing, ISBN- 
1549651205. 


Stakem, Patrick H. Microprocessors in Space, 2011, PRRB 
Publishing, ISBN-1520216343. 


Stakem, Patrick H. Computer Virtualization and the Cloud, 2013, 
PRRB Publishing, ISBN-152021636X. 


Stakem, Patrick H. What's the Worst That Could Happen? Bad 
Assumptions, Ignorance, Failures and Screw-ups in Engineering 


Projects, 2014, PRRB Publishing, ISBN-1520207166. 


Stakem, Patrick H. Computer Architecture & Programming of the 
Intel x86 Family, 2013, PRRB Publishing, ISBN-1520263724. 


Stakem, Patrick H. The Hardware and Software Architecture of the 
Transputer, 2011,PRRB Publishing, ISBN-152020681X. 


Stakem, Patrick H. Mainframes, Computing on Big Iron, 2015, 
PRRB Publishing, ISBN- 1520216459. 


81 


Stakem, Patrick H. Spacecraft Control Centers, 2015, PRRB 
Publishing, ISBN-1520200617. 


Stakem, Patrick H. Embedded in Space, 2015, PRRB Publishing, 
ISBN-1520215916. 


Stakem, Patrick H. A Practitioner's Guide to RISC Microprocessor 
Architecture, Wiley-Interscience, 1996, ISBN-0471130184. 


Stakem, Patrick H. Cubesat Engineeering, PRRB Publishing, 
2017, ISBN-1520754019. 


Stakem, Patrick H. Cubesat Operations, PRRB Publishing, 2017, 
ISBN-152076717X. 


Stakem, Patrick H. Interplanetary Cubesats, PRRB Publishing, 
2017, ISBN-1520766173 . 


Stakem, Patrick H. Cubesat Constellations, Clusters, and Swarms, 
Stakem, PRRB Publishing, 2017, ISBN-1520767544. 


Stakem, Patrick H. Graphics Processing Units, an overview, 2017, 
PRRB Publishing, ISBN-1520879695. 


Stakem, Patrick H. Intel Embedded and the Arduino-101, 2017, 
PRRB Publishing, ISBN-1520879296. 


Stakem, Patrick H. Orbital Debris, the problem and the mitigation, 
2018, PRRB Publishing, ISBN-/980466483. 


Stakem, Patrick H. Manufacturing in Space, 2018, PRRB 
Publishing, ISBN-1977076041. 


Stakem, Patrick H. NASA's Ships and Planes, 2018, PRRB 
Publishing, ISBN-1977076823. 


Stakem, Patrick H. Space Tourism, 2018, PRRB Publishing, ISBN- 


82 


1977073506. 


Stakem, Patrick H. STEM — Data Storage and Communications, 
2018, PRRB Publishing, ISBN-1977073115. 


Stakem, Patrick H. In-Space Robotic Repair and Servicing, 2018, 
PRRB Publishing, ISBN-1980478236. 


Stakem, Patrick H. Introducing Weather in the pre-K to 12 
Curricula, A Resource Guide for Educators, 2017, PRRB 
Publishing, ISBN-1980638241. 


Stakem, Patrick H. Introducing Astronomy in the pre-K to 12 
Curricula, A Resource Guide for Educators, 2017, PRRB 
Publishing, ISBN-198104065X. 

Also available in a Brazilian Portuguese edition, ISBN- 
1983106127. 


Stakem, Patrick H. Deep Space Gateways, the Moon and Beyond, 
2017, PRRB Publishing, ISBN-1973465701. 


Stakem, Patrick H. Exploration of the Gas Giants, Space Missions 
to Jupiter, Saturn, Uranus, and Neptune, PRRB Publishing, 2018, 
ISBN-9781717814500. 


Stakem, Patrick H. Crewed Spacecraft, 2017, PRRB Publishing, 
ISBN-1549992406. 


Stakem, Patrick H. Rocketplanes to Space, 2017, PRRB 
Publishing, ISBN-1549992589. 


Stakem, Patrick H. Crewed Space Stations, 2017, PRRB 
Publishing, ISBN-1549992228. 


Stakem, Patrick H. Enviro-bots for STEM: Using Robotics in the 
pre-K to 12 Curricula, A Resource Guide for Educators, 2017, 
PRRB Publishing, ISBN-1549656619. 


83 


Stakem, Patrick H. STEM-Sat, Using Cubesats in the pre-K to 12 
Curricula, A Resource Guide for Educators, 2017, ISBN- 
1549656376. 


Stakem, Patrick H. Lunar Orbital Platform-Gateway, 2018, PRRB 
Publishing, ISBN-1980498628. 


Stakem, Patrick H. Embedded GPU's, 2018, PRRB Publishing, 
ISBN- 1980476497. 


Stakem, Patrick H. Mobile Cloud Robotics, 2018, PRRB 
Publishing, ISBN- 1980488088. 


Stakem, Patrick H. Extreme Environment Embedded Systems, 
2017, PRRB Publishing, ISBN-1520215967. 


Stakem, Patrick H. What's the Worst, Volume-2, 2018, ISBN- 
1981005579. 


Stakem, Patrick H., Spaceports, 2018, ISBN-1981022287. 


Stakem, Patrick H., Space Launch Vehicles, 2018, ISBN- 
1983071773. 


Stakem, Patrick H. Mars, 2018, ISBN-1983116902. 


Stakem, Patrick H. X-86, 40” Anniversary ed, 2018, ISBN- 
1983189405. 


Stakem, Patrick H. Lunar Orbital Platform-Gateway, 2018, PRRB 
Publishing, ISBN-1980498628. 


Stakem, Patrick H. Space Weather, 2018, ISBN-1723904023. 


Stakem, Patrick H. STEM-Engineering Process, 2017, ISBN- 
1983196517. 


84 


Stakem, Patrick H. Space Telescopes, 2018, PRRB Publishing, 
ISBN-1728728568. 


Stakem, Patrick H. Exoplanets, 2018, PRRB Publishing, ISBN- 
9781731385056. 


Stakem, Patrick H. Planetary Defense, 2018, PRRB Publishing, 
ISBN-9781731001207. 


Patrick H. Stakem Exploration of the Asteroid Belt, 2018, PRRB 
Publishing, ISBN-1731049846. 


Patrick H. Stakem Terraforming, 2018, PRRB Publishing, ISBN- 
1790308100. 


Patrick H. Stakem, Martian Railroad, 2019, PRRB Publishing, 
ISBN-1794488243. 


Patrick H. Stakem, Exploiting the Moon, 2019, PRRB Publishing, 
ISBN-1091057850. 


Patrick H. Stakem, RISC-V, an Open Source Solution for Space 
Flight Computers, 2019, PRRB Publishing, ISBN-1796434388. 


Patrick H. Stakem, Arm in Space, 2019, PRRB Publishing, ISBN- 
9781099789137. 


Patrick H. Stakem, Extraterrestrial Life, 2019, PRRB Publishing, 
ISBN-978-1072072188. 


Stakem, Patrick H. Riverine Ironclads, Submarines, and Aircraft 
Carriers of the American Civil War, 2019, PRRB Publishing. 


Stakem, Patrick H. Submarine Launched Ballistic missiles, ISBN- 
978-1088954904. 


85 


Stakem, Patrick H., Space Command, Military in Space, ISBN- 
978-1693005398 . 


Robotic Exploration of the Icy moons of the Gas Giants, ISBN- 
979-862143 1006. 


Hacking Cubesats, 2020, ISBN-979-8623458964. 


History & Future of Cubesats, PRRB Publishing, ISBN-979- 
8649179386. 


Hacking Cubesats, Cybersecurity in Space, 2020, PRRB 
Publishing, ISBN-979-8623458964. 


Powerships, Powerbarges, Floating Wind Farms: electricity when 
and where you need it, 2021, PRRB Publishing, ISBN-979- 
8716199477. 


Hospital Ships, Trains, and Aircraft, 2020, PRRB Publishing, 
ISBN-979-8642944349. 


86 


